Fund a Bug Bounty or CVE Research Project From Fans

Independent security researchers can fund a bug bounty or CVE research project by setting a Wishlist / Project Support goal on FanBell with a stated target (lab hardware, disclosure time, tooling) and a visible progress bar, letting followers back the research directly instead of waiting on a single vendor payout.

FanBell is free to start with no monthly fee and applies a 12% platform fee only when a fan pays (pricing).

Vulnerability research is unpaid until a finding lands: triage, reproduction, write-up, and coordinated disclosure all happen before any bounty check clears, if one clears at all. HackerOne's 9th Annual Hacker-Powered Security Report found that bug bounty programs on its platform collectively paid researchers $81 million, a 13% increase over the prior year (HackerOne press release). That money is also concentrated: HackerOne's same 9th Annual Hacker-Powered Security Report reports that the platform's top 10 programs alone accounted for $21.6 million of the $81 million paid out (HackerOne — Hacker-Powered Security Report, 9th Edition), so the exploratory hours that lead to a finding are rarely what gets rewarded.

What counts as a fundable research project?

A fundable research project is a scoped piece of independent security work with a named target, a stated budget, and a stopping point — reverse-engineering one device class, auditing an open-source dependency for a specific bug class, or covering the disclosure work behind a single CVE candidate. An open-ended "pay me to hack things" ask is not fundable.

On FanBell, a scoped research goal becomes a Wishlist / Project Support page: the researcher sets a target amount and description, fans send money toward it, and a progress bar shows how close the goal is to funded (how it works). A Wishlist goal is cash toward a stated goal, not a tiered-rewards system — a backer is supporting the research, not purchasing a shipped product, an equity stake, or a guaranteed deliverable.

Typical funded scopes include a specific target device or codebase, the disclosure-coordination window itself, testing hardware or lab time, or a defined research sprint (for example, "two weeks auditing this library's auth flow"). Naming the scope up front is what makes a research ask fundable rather than vague. Scale is the reason a named target matters: the CVE Program's own site states that more than 367,000 CVE Records are currently accessible by keyword search or download (CVE.org), so "security research" as a category tells a backer nothing until a researcher names the thing being researched.

Is this different from a company's bug bounty program?

Yes. A FanBell Wishlist / Project Support goal funds a researcher's time before or alongside any bounty submission, while a vendor's bug bounty program pays only for an accepted, validated finding on the vendor's own severity scale and process. The two run in parallel: fans fund the work, and the vendor's program (if one exists) rewards the report.

Corporate and platform bounty programs operate at a scale FanBell does not touch: HackerOne's 9th Annual Hacker-Powered Security Report draws on more than 580,000 validated vulnerabilities reported to date across nearly 2,000 enterprise programs active in the past year. Bug bounty payouts on HackerOne are earned per validated report, after vendor triage, and are entirely separate from any FanBell funding goal.

A Project Support goal instead funds the researcher directly, on the researcher's own timeline, regardless of whether any single submission is ultimately accepted or rewarded. Funding the work up front and getting paid per accepted finding are two different economics, and a researcher can use both at once.

How do you write a fundable project description?

A fundable project description names the research target, the deliverable, the budget line items, and what happens with the outcome. A vague "support my hacking" appeal gives a prospective backer nothing to evaluate, so a project description should read like a short project brief with a dated stopping point rather than a general request for support.

Include what you're researching (a device class, a library, a protocol), why it matters (a plausible risk, not a sensational claim), what the funding covers (time, tools, hardware), and what backers get in return — visibility into progress and, where appropriate, a public write-up once responsible disclosure is complete. Do not promise access to unpatched vulnerability details before disclosure, because early release would undercut the coordinated-disclosure process the research depends on.

CVE assignment runs through the CVE Program's own numbering authorities and rules, not through FanBell or any funding platform. A CVE Numbering Authority (CNA) assigns and publishes a record only once a report meets the published criteria, and the CVE Board approved CNA Operational Rules Version 4.2.0 on August 20, 2026, effective August 25, 2026. Funding covers a researcher's ability to do the work; funding does not shortcut or replace CVE assignment. Finding the right CNA is itself part of the funded disclosure work: the CVE Program's Q1 CY 2026 report counts 514 partner organizations — 511 CNAs and 3 CNAs of Last Resort — across 43 countries (CVE.org — Q1 2026 Program Report).

Should this be a funded goal or a paid Q&A instead?

Use a Project Support goal to fund your own open-ended research, and use a priced Paid Private Question when someone else wants a quick expert opinion on something specific. A funding goal has many backers and no single buyer; a paid question has one buyer and one answer, so price and describe the two separately.

A Paid Private Question fits a narrow, one-off ask — "does this link look like phishing?" — where a fan pays for a typed answer to their own question, and the creator replies by text or voice with no file exchanged in either direction. Independent CVE research, by contrast, has no single asking fan and is funded by many people backing a goal the researcher defined.

Most independent researchers fit this work around employment: 81% of the more than 2,000 hackers surveyed for Bugcrowd's Inside the Mind of a Hacker 2026 report work full-time in a security-related field (Bugcrowd — Inside the Mind of a Hacker), and buying back research hours is exactly what a Project Support goal is for.

If a fan instead wants a structured audit of their product or codebase rather than your independent research, that work is a paid deliverable rather than a funding goal. Scope a paid audit separately from a research fund so backers never confuse "support my research" with "hire me for a security review."

How does CVE and disclosure timing affect a funded project?

Disclosure timing on a funded research project is set by the CVE Program, the affected vendor, and any coordinating body — never by the funding goal. A CVE Record publishes only after a CNA processes and releases it, so a project description should warn backers that disclosure can lag the funded research by weeks or months.

Published output is steady but externally paced: the CVE Program's own quarterly report recorded 12,796 CVE Records published in Q4 CY 2025, a 9% increase over the 11,738 records published in Q3 CY 2025. Enrichment behind those records is under strain — NIST has said its National Vulnerability Database cannot keep pace with submission volume:

"We enriched nearly 42,000 CVEs in 2025 — 45% more than any prior year. But this increased productivity is not enough to keep up with growing submissions." — NIST, April 2026

Vendor-facing deadlines are equally external to any funding page. Google Project Zero publishes a fixed deadline policy that researchers frequently adopt as a reference point:

"Project Zero follows a 90+30 disclosure deadline policy, which means that a vendor has 90 days after Project Zero notifies them about a security vulnerability to make a patch available to users." — Google Project Zero, Vulnerability Disclosure Policy

Coordinators apply their own clocks too: CISA states that where a vendor is unresponsive or will not commit to a reasonable remediation timeframe, CISA may disclose a vulnerability as early as 45 days after initial contact (CISA — Coordinated Vulnerability Disclosure Program). Set backer expectations against the vendor, coordinator, and CVE Program clocks rather than against the funding page: fund the research phase, then state in project updates that disclosure and CVE publication follow a timeline the researcher does not control.

What should the funding goal actually cover?

A funding goal should cover concrete, named research costs rather than a general living stipend, because a named cost lets a fan see exactly what a contribution buys. Common line items include lab or test hardware, cloud and VM time for fuzzing or analysis, dataset or tool licenses, and blocked-off research hours aimed at one specific target — the same named-cost structure works for crowdfunding an open dataset release when the deliverable is data rather than a vulnerability report.

Tool licenses are the easiest line item for a backer to picture, because they carry a published price: PortSwigger's own store lists Burp Suite Professional at $499 per user per year (PortSwigger — Buy Burp Suite Professional). The four fund targets in this section's table are illustrative starting points rather than a pricing guarantee, because actual costs depend on the research target, the tooling involved, and the researcher's own pace. A researcher sets the goal amount and its written description, and FanBell shows contributions against that target on a progress bar.

Frequently asked questions

FanBell does not run a bug bounty program, pay per-finding rewards, or require a certification or follower minimum to launch a Wishlist / Project Support goal. The answers below cover FanBell's fee on a funded research project, what backers see before disclosure, and how a funded goal differs from a paid audit.

Does FanBell pay out bug bounties itself?

No. FanBell does not run a bug bounty program and does not pay per-finding rewards. A Wishlist / Project Support goal funds independent research time, and any per-finding bounty still comes from the vendor or platform whose bug bounty program the researcher submits to.

Can backers see the vulnerability details before disclosure?

Project descriptions and updates are the researcher's to write, but responsible-disclosure practice means holding unpatched vulnerability specifics until coordinated disclosure completes. Use funding updates to share research progress and scope, not exploit details that could put users at risk before a fix ships.

What's the difference between this and a paid security audit?

A funded Wishlist goal supports a researcher's own open-ended work, while a paid security audit is a scoped deliverable for one buyer's product, sold as a Creator Service with a set price and turnaround. If a fan wants a review of their codebase rather than funding for independent research, that request is a service, not a funding goal.

What does FanBell charge on a funded project?

FanBell is free to start with no monthly fee and takes a 12% platform fee only when a fan contributes to a goal. There is no follower minimum to launch a Wishlist / Project Support goal, and payouts run through Stripe once onboarding is complete. Stripe's published US rate of 2.9% + 30¢ per successful card transaction, plus 1.5% for international cards, applies on top of and separately from FanBell's fee (Stripe — Pricing & Fees).

Do I need to be a professional pentester to fund research this way?

FanBell's setup process does not list a professional certification as a prerequisite for creating a Wishlist / Project Support goal. Represent your background accurately in the project description, and follow the disclosure norms and legal boundaries (such as authorized-testing scope) that apply to the specific research being funded.

Create your free FanBell page and give your next research project a funded goal instead of a free-time side quest.