$_ stdout
~/posts/bounties.md · on main · 49 min read
/**
* @topic#bugbounty #aisecurity #disclosure #cve #opensource
* @statuspublished
*/

Mutiny on the Bounty: How Autonomous Discovery Broke Vulnerability Disclosure

For two decades, finding a vulnerability was expensive and triaging one was cheap. Models flipped that ratio. Discovery now costs cents, triage still costs a human afternoon, and the intake funnels of bug bounties, open-source security lists and the CVE program are buckling under the difference.

The strain is already visible. curl closed its bounty after valid reports fell to below 5% of submissions, the Linux kernel's private security list went from a few reports a week to five to ten a day, OpenSSL's inbox grew roughly eightfold, and the CVE program is on track for more than 66,000 entries while the count of exploitable flaws barely moves. Mixed into the flood are real zero-days found by the same models, written in the same format and sent through the same channels, so a filter strict enough to drop the slop drops them too. Blunt, unsophisticated filters fail.

This post walks through the economics, the four tiers of machine-generated reports, the frontline responses and the research on bounty design, and argues that submissions are now cheap while a working proof of concept is valuable, because only execution settles a claim. The answer is an intake stack that checks the report instead of the reporter, with a sandboxed proof of concept before any human looks, and rewards that pay for verified patches and triage labor, not for volume.

The stakes are measurable. Between December 2025 and July 2026, programs changed their rules about once a month: curl ended its bounty, HackerOne paused the Internet Bug Bounty and then cut its rates by up to 89%, and GitHub cut its top public reward from $30,000 to $10,000. Yet Google paid a record $17 million in 2025. The money did not vanish. It moved toward findings that arrive with proof: in DARPA's AI Cyber Challenge, submissions anchored in a working proof of vulnerability were right 93% of the time, against 33% for model reasoning alone. What is being repriced is the cost of proving a finding, and who pays for it is the question this post ends on.

BL Dr. Ben Livshits October 12, 2026 · 76 commits

For about two decades, bug bounties were a bargain. A company or a maintainer posted a price, a global crowd of people did the slow work of finding flaws, and a triager read each report that came in. Every part of that bargain rested on one assumption: finding is slow.

Economists flagged a flaw in that bargain early. In 2005, Kannan and Telang compared the two ways to handle a vulnerability once it is found: (1) report it to a neutral body that verifies it and publishes an advisory everyone can patch from, or (2) sell it to a firm that pays per finding and resells what it learns to subscribers. The market version, they concluded, usually serves the public worse, because a firm that profits from the information has an incentive to spread it or sell it elsewhere rather than see it fixed.

The crew of the original Bounty mutinied against a captain. This crew is made of models that never sleep, and its captain is whoever reads the inbox. Nobody planned for that.

This post follows what happened when the assumption broke: the economics and what the models can now do, the four kinds of machine-generated report, the responses at curl, the Linux kernel, Node.js, Chromium and Immunefi, the strain on the platforms and the CVE program, and what the bounty-economics research and DARPA's AI Cyber Challenge say a workable intake looks like.

My core argument is that the scarce resource is verification, not discovery.

Infographic titled 'Mutiny on the Bounty: Fixing the AI Vulnerability Flood. How AI models inverted vulnerability discovery economics and the framework for execution-grounded defense.' The crisis: a cloud labeled AI model discovery, with a 'cents' price tag, pours a stream of report pages toward a cracked dam, captioned 'Discovery cost collapsed to cents while triage remains human-bound.' A human triage queue, tagged 'flat cost', shows a stressed maintainer beside the statistic 'Valid submission rates plunged below 5% for major projects', with curl closing monetary bounties as the example. A sailing ship labeled Bounty System is tossed in the flood. Four report tiers, from pure slop to valid zero-days: pure slop, decontextualized logic flaws, plausible but unexploitable, and valid zero-days. The fix, execution-grounded verification: dynamic execution in a sandbox is the only ground truth, a multi-tier intake stack with machine-readable schemas and isolated container runs filters reports, and a verified path leads to a treasure chest of rewarded validated fixes under the advice to pay for verified patches, not raw discovery. A DARPA AIxCC panel shows PoV plus patch bundles at 93% accuracy against patch plus SARIF only at 33%.
// Figure 1. The post in one image: AI-driven discovery floods a human triage queue, and execution-grounded verification at intake is the fix.

01 The Economics Inverted

Vulnerability disclosure ran for roughly twenty years on an unwritten compact: finding was hard, triaging was relatively easy. A researcher spent days or weeks on reverse engineering, taint tracking, hand audits or a fuzzing harness before a report existed. That effort was a quality gate nobody designed. Whitehats and blackhats alike submitted what they believed was real, because the payoff, in money, in CVE credit or in reputation, had to justify the labor.

The receiving side enjoyed the opposite asymmetry. Reading a good report, running its reproducer and applying a supplied patch took a fraction of the time it took to find the bug. Write discovery cost as Cd and triage cost as Ct. The queue stays healthy while Cd/Ct is much greater than one, and crowdsourced programs on HackerOne and Bugcrowd, both founded in 2012, flourished on exactly that condition. The table below dates the programs that grew up on that condition.

YearProgramWhat it established
1995Netscape Navigator 2.0 betaThe first commercial bounty: cash and merchandise for security bugs in a browser beta
2004Mozilla Security Bug BountyThe first major open-source program, paying $500 for critical bugs on outside sponsors' money
2010Google ChromeA vendor-run program for a mainstream product, announced in January
2012HackerOne and BugcrowdPlatforms that run intake, triage and payment for other companies' programs
2013Internet Bug BountyMicrosoft and Facebook fund rewards for flaws in widely used open-source software; HackerOne paused it in 2026
// Figure 2. Early milestones of the bug bounty model, from a browser beta in 1995 to the platform era.

The Cost Collapse Happened on One Side Only

Frontier models and agentic cyber reasoning systems read syntax trees, code graphs, commit histories and weakness catalogs, and they audit millions of lines in seconds. What took a senior engineer months now costs dollars, or cents. But the collapse is only on the generation side. Deciding whether a reported memory anomaly crosses a real security boundary, whether the component is reachable in a real deployment, and whether the proposed fix quietly breaks something else is still human work, bounded by human attention.

Two-row illustration. Top, classical economics: a researcher under a clock and a magnifier works through a document marked with dollar signs, one expensive finding yields a small stack of mostly-real reports, and a single triager clears them from a small tray — a sustainable equilibrium. Bottom, the post-2024 inversion: a robot beside a one-cent coin marks near-zero discovery cost, and the same reports arrive as a pile of documents that buries the triager — systemic gridlock.
// Figure 3. The classical discovery-to-triage ratio against the post-2024 inversion.

With Cd/Ct now well below one, volume grows without limit while per-item triage cost stays flat or rises, since subtly wrong machine reasoning is harder to refute than an obviously wrong human report.

That is the triager's dilemma. Dismiss reports out of hand and you may ignore a genuine machine-found zero-day. Investigate every plausible one and you stall the project and burn out the people doing it.
Queue equilibrium

Cd/Ct ≫ 1. Finding is expensive, triage is relatively cheap, and volume stays proportional to human bandwidth.

Queue exhaustion

Cd/Ct ≪ 1. Generation costs cents, verification still costs human hours, and volume grows without limit.

What the Models Can Do

The inversion is not a passing phase, and the capability curve is why. Heuristic pattern matching gave way to LLM-guided fuzzing, which fully agentic cyber reasoning systems (CRSs) have now passed; these combine frontier models with execution sandboxes, dynamic taint analysis, symbolic execution and iterative feedback. The landmark systems are below.

Two-band illustration. Top, six labelled pictograms trace the loop: a source file for the target source or binary, a node graph for the semantic graph parser, a lightbulb for the model-formed vulnerability theory, a fuzzing funnel for the dynamic taint fuzzer, a magnifier over a trace log for the GDB and ASan trace engine, and a bolt for the weaponized exploit. Bottom, four cards summarize landmark systems: Big Sleep (SQLite underflow caught before use, a 20-year-old OpenSSL bug), Mythos (6,202 high or critical findings across 1,000-plus repositories, with a separate Claude Opus 4.6 result of 22 Firefox vulnerabilities), Astra (100% on ExploitBench against Chrome V8) and XBOW (number one on the HackerOne US leaderboard in June 2025, submitting nearly 1,060 vulnerabilities).
// Figure 4. The agentic exploit loop and four landmark autonomous-discovery systems with their reported results.

Google's Naptime, later Big Sleep, gives an LLM agent debugging tools, cross-reference navigation, targeted fuzzing and sanitizer feedback in a sandbox, and lets it form hypotheses and refine inputs. It caught a SQLite buffer underflow before attackers used it, then found an OpenSSL bug that had escaped human reviewers and fuzzers for twenty years.

Anthropic's Mythos work showed models finding deeply nested logic flaws and building multi-stage exploit chains that defeat ASLR and DEP, with 6,202 high- or critical-severity findings across more than 1,000 open-source repositories. In a separate collaboration, Claude Opus 4.6 found 22 Firefox vulnerabilities in two weeks, 14 of them rated high severity.

OpenAI's Astra, its first model rated cyber-critical under its preparedness framework, scored 100% on ExploitBench and, in expert-led assessments against a hardened browser, built a full chain that escaped the sandbox. It sits alongside OpenAI's Daybreak program, which has a defensive Blue track and a restricted Red track. XBOW, the fourth card, is taken up with the valid reports in the next section.

The New Clock

These capabilities eat the defender's grace period. Historically, a disclosure started a race measured in days or weeks while attackers reversed the patch and wrote a stable exploit. That race is gone.

A stopwatch for a 29-minute average breakout time after initial access. Below, a timeline of the exposure gap: a bolt for first exploitation 7 days before the patch, a shield for the patch deployed 43 days after, and a 50-day bar spanning the two, with a note that timing baselines differ by source and that the axis is anchored at patch release.
// Figure 5. The timing of the triage crisis, with breakout, exploitation and patch deployment placed against patch release.
// the new clock

CrowdStrike puts the average adversary breakout time at 29 minutes, and Mandiant's M-Trends 2026 has the average time-to-exploit at negative seven days, meaning exploitation in the wild a week before public disclosure.

On the other side of the same race, University of Illinois researchers showed GPT-4 autonomously exploiting 87% of known one-day CVEs from the plain-text advisory alone, while enterprise patching still takes a median of 43 days.

The Zero Day Clock, a public scoreboard built from public exploitation feeds, puts these numbers in one place, and its central claim is that the disclosure system has inverted: the warning now arrives after the attack. Its headline figures are Unit 42's finding that 80% of public exploits appear before the CVE, on average 23 days ahead of it, and VulnCheck's count that 28.3% of exploited vulnerabilities are weaponized within a day. It is a campaign as much as an instrument, and it declines to publish a single time-to-exploitation metric, so I read it for direction, not as a number to quote.

Attackers run on seconds and minutes, defenders on weeks and months.

The Open-Source Commons Pays

The bill for that inversion lands hardest on open source. These projects are public goods kept alive by volunteers, and they used to replenish their maintainers from the contributor pool: fix a typo, then a bug, then earn commit rights. Automated submitters now collect the upside of rewards and notoriety while pushing the entire verification cost onto maintainers. A study of 294 repositories and more than two million pull requests and issues found that pull-request volume rose in 2025 while merge rates fell. For one-time contributors, the merge rate dropped by 18.18% against a counterfactual (Afroz et al., 2026), an effect the authors call an AI-DDoS.

The strain shows across projects. OpenSSL's Matt Caswell wrote in October 2026 that "in 2025, our security address received approximately nine separate reports and enquiries every month and now that number is as high as 70," while "the pool of skilled people available to handle that workload is not growing at the same rate."

Godot's Rémi Verschelde wrote that "AI slop PRs are becoming increasingly draining and demoralizing for #Godot maintainers... I don't know how long we can keep it up." FFmpeg maintainers pushed back on large companies whose automated scanners filed dozens of valid but low-impact tickets with no patches, calling it "CVE slop" that moves the corporate remediation burden onto unpaid volunteers.

Maintainers respond by closing the perimeter: blanket bans on unsolicited submissions, shuttered intake paths and, at CycloneDX, a closed GitHub bounty program after a flood of almost entirely AI-generated false positives. The move is rational for each project and corrosive for all of them, because it severs the contributor pipeline that open source depends on to survive.

More CVEs, Not More Exploits

The registry shows the same pressure. FIRST reported that 2026 CVE disclosures ran 46.3% above baseline forecasts, putting the year on track for more than 66,000 published vulnerabilities. But a CVE records that a flaw exists, not that anyone can exploit it, and only about 1.4% of indexed CVEs, roughly 4,920 of 352,357, have ever been confirmed exploited. At the CVE Program Virtual Forum, a central finding was that raw discovery volume no longer tracks exploitability. Models are good at theoretical invariant violations, unhandled edge cases and faults in unreachable code. Filter the same records against CISA's Known Exploited Vulnerabilities catalog or an EPSS threshold above 10%, and the count of practically weaponizable flaws looks comparatively stable. I take that gap apart in Patchmageddon? Or Not So Much.

Enterprises still pay the tax. Compliance regimes, SLAs and automated scanners push security teams to document and remediate thousands of CVEs that nobody will ever exploit, and teams often spend longer arguing over whether a flaw matters in their context than it would take to rewrite the code.

The one-CVE-per-anomaly model was built for a world where anomalies were scarce.

02 Anatomy of the Flood

The reports hitting triage queues are not one stream. They span a spectrum from fabricated text to nearly undetectable logic errors, and the defense you build depends on which end you are facing. Four tiers cover that range:

  1. Crude hallucinations ("pure slop"). References non-existent code, fabricated CVEs and invented APIs, in generic LLM prose. Each report is cheap to reject, but at volume they pollute the queue.
  2. Decontextualized invariant violations. Cites real code lines but ignores the threat model, for example by requiring physical root access. Very expensive to refute, since it takes deep architectural verification.
  3. Plausible synthetics ("high-fidelity fakes"). Fabricates reachable data-flow paths, with real function names and hallucinated memory states. Extremely expensive: maintainers spend days proving non-exploitability.
  4. Valid automated discoveries. True zero-days from the same models, where a proof of vulnerability or an exploit exists that can be run, even if it arrives later in the thread. High-value to triage, and they demand rapid patch orchestration and downstream fixes.

Tier 1: Crude Hallucinations

The most visible tier is unedited model output. A novice prompts a commercial LLM to audit a repository and write a HackerOne-style report, and the result carries recognizable markers. It cites functions, files or commit hashes that do not exist. It attributes the codebase to CVE identifiers from unrelated software. Severity is uniformly Critical or High, with boilerplate CVSS vectors claiming remote code execution and no justification.

The prose is all executive summary and dramatic impact, and the remediation advice reads "sanitize all inputs" and "ensure robust bounds checking" with no diff and no reproducer. Each of these is cheap to reject.

However, at volume, they pollute the queue anyway.

Tier 2: Decontextualized Invariant Violations

Here the code snippet is transcribed correctly and the claim is still wrong, because it ignores the threat model. An unchecked copy or a failed assertion in a command-line tool is flagged, but reaching it requires root, physical console access, or a debug flag disabled in production builds.

Under the project's published threat model, privileged local execution is normal operation, not a boundary breach. The report is nevertheless dressed in formal security vocabulary, and refuting it means a maintainer spending hours reconstructing context.

Tier 3: Plausible Synthetics

Frontier models have moved past crude errors. The Chromium security team and maintainers of systems libraries describe reports that name every function on a call chain, get the parameter types right and lay out a coherent heap-corruption or use-after-free story.

What the model hallucinates is dynamic reachability. It misses the upstream validation, the state constraint or the lock that makes the condition impossible at runtime. Daniel Stenberg, who created curl, put the economics bluntly, as The Register quoted him:

"The better the crap, the longer time and the more energy we have to spend on the report until we close it."— Daniel Stenberg, as quoted by The Register

Plausible fabrication is the expensive kind.

Tier 4: Valid Automated Discoveries

Mixed into the noise are real, dangerous zero-days (the first section describes the systems behind them): the twenty-year-old OpenSSL flaw found by Google's Big Sleep, the Linux kernel's "Copy Fail" bug (CVE-2026-31431), and multi-step logic bypasses. They come from the same models, in the same disclosure template, through the same trackers as Tiers 1 to 3, and the proof often arrives after the first message rather than with it: the kernel's guidance tells reporters to say a reproducer exists and share it only if maintainers ask, while Chromium's teams get a PoC as a follow-up. A keyword blocker or regex filter aimed at the marks of slop, the boilerplate CVSS vector, the Critical severity claim, "sanitize all inputs", hits those reports too, which is why triage teams cannot deploy keyword blockers or regex filters without risking the failure they are trying to avoid.

The Firefox collaboration shows what a good one looks like: 22 vulnerabilities in two weeks, 14 rated high severity, found by Claude Opus 4.6 in work with Mozilla. The kernel's own documentation concedes the same point when it calls AI-assisted review "an efficient means to find bugs in rarely explored areas." What these have in common is not the model but the evidence, a reproducer that runs, and that, rather than the shape of the report, is what separates a Tier 4 report from a Tier 3 one.

XBOW and the Autonomous Hunter

Tier 4 has a commercial face too. Autonomous agents such as XBOW scan web perimeters without human direction, find logic flaws, validate SQL injection and cross-site scripting against live targets, construct working exploits and file verified reports.

In June 2025, XBOW reached first place on HackerOne's US leaderboard, submitting nearly 1,060 vulnerabilities. If an agent can audit an attack surface around the clock for a small fraction of what thousands of human hunters cost, the case for noisy, open-ended public programs weakens. Security leaders now ask why not license a swarm and audit internally. The incidents where swarms were turned to offense are catalogued in Agentic Swarms: Weaponized and Emergent.

Bounty Farming and Extortion

Tier 4 is agents hunting bugs against a security budget. The first three tiers are the same automation pointed the other way, and what it runs on is incentives: platforms gamified auditing with payouts, leaderboards, badges and reputation scores, and for researchers in lower-income regions a single payout can cover months of living costs. Once generative AI removed the friction, farming was automated end to end: scripts watch public GitHub, GitLab and package-registry feeds for new commits, diffs go through batch APIs to a reasoning model with a prompt built to flag flaws aggressively, the JSON comes back formatted as a disclosure-style Markdown report with a synthetic risk matrix, and the reports are broadcast to trackers, security aliases and platform endpoints across dozens of repositories at once.

Two-band illustration. Generation reads left to right: a code-repository icon, a row of three model-agent heads that scan diffs and synthesize reports, and a fan of formatted markdown reports. Delivery reads right to left: three envelopes broadcast in high volume to HackerOne, Bugcrowd and mail, reaching a maintainer beside an overflowing tray, and on to a stacked backlog marked with a warning sign. Footer: cost of generation is cents, cost of verification is human hours.
// Figure 6. The automated bounty-farming pipeline, from repository feed to maintainer inbox.
// the extortion variant

A nastier variant has emerged. Maintainers now routinely get emails claiming an AI scanner found a critical flaw, with an ultimatum: acknowledge it, apply an unverified patch or pay a bounty, or the finding goes public, or to downstream enterprise customers, at the 90-day mark.

The maintainer either abandons the roadmap to disprove a threat that does not exist or risks the reputational hit. It is ransomware without the malware: nothing is encrypted, and the threat alone is the lever.

The Negative-Day Window

The registry lags the code. When a maintainer fixes a vulnerability, the fix lands on GitHub, and a CVE may follow weeks or months later, or never. The gap between the public patch and the public advisory is the negative-day window: the flaw is real, the diff points straight at it, and no advisory has reached the feeds that scanners match against, so software composition analysis stays silent about code that is already exploitable. AISLE, which mines commit streams for that signal, calls the silent cases negative-day vulnerabilities.

How long the window stays open varies enormously, and the tail is what matters.

// the window, measured

Of 39 windows AISLE collected from the first quarter of 2026 and earlier, seventeen closed the same day and the median was about a day; Django's and requests' closed in about two hours.

The tail is where the exposure sits. Authlib's removal of the JWT alg: none path took 30 days to reach CVE-2026-28802, and axios took about five months, from an October 30, 2025 fix to the CVE-2026-39865 advisory on April 8, 2026. The long tail pulls the average to 12 days.

The registry is also a fraction of the whole: a study AISLE cites, Michael Bommarito's scrutiny-gradient analysis of 1,139,828 commits across 22 Linux base-system repositories, found a security signal in 2.03% of commits and a CVE for only 5.6% of those.

How far that window has collapsed for exploitation is the subject of The Collapse of the Vulnerability Window.

Reading Commits at Scale

The negative-day window can be watched at ecosystem scale. AISLE benchmarked 21 models on the narrower question (does this commit fix a security problem?) over a 40-case corpus of 323 commits, and found that a single structured call on a mid-priced model flagged 90% of the known fixes at roughly $0.001 per commit; the best reach was 95%, at thirteen times the price, and the largest reasoning models did worst. Projected to 100,000 commits, the cheap harness costs about $96.

The work is also a supply-chain risk of its own: the author of a commit controls the diff, the message and the pull-request text the reviewer reads, so a commit-reading agent has to assume the commit is attacking it. AISLE's answer is to give the classifier no tools, no secrets and no network, wrap untrusted text in random per-request tags, escalate to a sandboxed agent only when the classifier asks for an investigation, and trace every call.

That lands on the discipline the rest of this post keeps returning to: a model's verdict on a diff is a hypothesis, not evidence. It becomes evidence when an executable trigger runs against the vulnerable and the fixed revision, or a maintainer confirms it.

Slopsquatting

Generative AI also creates new supply-chain surface, not just risk in code that already exists. Coding assistants hallucinate dependencies. Asked for an obscure cryptographic routine, a model invents a plausible package name such as jwt-validator-extended and imports it. Models share training data and biases, so many developers in many organizations get the same invented names. Attackers query models at scale across thousands of coding tasks, collect every package name that does not exist in the registry, register those names on npm and PyPI, and stage placeholders or multi-stage stealers.

The next developer who pastes AI-written code and runs npm install or pip install pulls the attacker's package into a workstation or a CI pipeline. When researchers find these packages, they file automated CVE requests and supply-chain alerts, which adds yet more noise to the same overloaded systems.

The Abandoned Commons

The sharpest exposure is where nobody upstream can patch at all: end-of-life software. Enterprise applications sit on trees of hundreds of transitive dependencies, and many widely used components, such as AngularJS, Vue 2, Python 2.7 and old .NET, Spring and Apache versions, are past support with no maintainers, locked trackers and nobody left to publish an advisory. Discovery engines do not care about support status. Big Sleep, Astra and XBOW will audit an abandoned library as readily as an active one.

Two-lane illustration of labelled pictograms. Top lane, supported software: a magnifier over a page, a report, a person, a patched page and a shipped-update arrow, so the defensive loop closes under strain. Bottom lane, end-of-life software: the same find, then a bolt, a globe under attack and a cracked shield, with no maintainer and no patch possible feeding back into the compromise: zero defensive capacity and permanent structural exposure.
// Figure 7. The defensive lifecycle for supported software and for end-of-life software.

Abandonment is not limited to old frameworks. extract-zip, an npm package with 23 million downloads in the first week of October, has had no release since June 2020 and no commit since August 2021. In 2026 it collected two symlink-based CVEs, CVE-2026-56876 from CISA in June and CVE-2026-19693 from Seal Security in August, while a security report filed on April 30 still has no reply. Puppeteer's browser installer replaced it in May. Seal, which sells patched builds of such packages, reports that an LLM found the flaw and a proof of concept from a one-line audit prompt in minutes, and counts 11% of top-downloaded packages as abandoned; both figures are the vendor's own.

For supported software the defensive loop closes under strain. For EOL software, the loop does not exist.
// patching by model

Handing legacy stacks to a model to patch is no way out. A Veracode study of more than 100 LLMs across 80 coding tasks found that 45% of generated samples introduced an OWASP Top 10 vulnerability, and that Java was the riskiest language, with a security failure rate above 70%.

Sonatype found LLMs hallucinated non-existent package versions 28% of the time during automated dependency upgrades, sometimes recommending malicious typosquats.

03 Case Studies

The strain is no longer theoretical. Four large projects, each pulling a different lever, show the range of responses; Immunefi and Cisco follow.

TargetPrimary stressorDefensive counter-strategy
curlBounty validity collapsed below 5% under LLM slopMonetary bounty program terminated; incentive eliminated
Linux kernelPrivate security list intake rose from 2 to 3 a week to 5 to 10 a dayAI findings treated as public; tested fix and reproducer expected
Node.jsOver 30 low-quality reports in one month, past what the team could handleMinimum HackerOne Signal required; newcomers contact the team directly
Google ChromiumInflux of plausible fakes with hallucinated execution tracesStrict fix SLAs; reachability claims need a PoC or ASan trace; closed bugs reused as evaluation cases
// Figure 8. Stressor and defensive response at curl, the Linux kernel, Node.js and Chromium.

curl: Ending the Bounty

On January 31, 2026, Stenberg shut down curl's six-year-old HackerOne bounty program. It had been an industry model: 87 confirmed vulnerabilities and more than $100,000 paid to independent researchers since 2019. Then came the slop. Volunteers were consumed by investigating convincing, well-written, fabricated reports, a grind Stenberg called "death by a thousand slops," the title of his July 2025 post. His January 2026 post put the damage in numbers:

"Previous years we have had a rate of somewhere north of 15% of the submissions ending up confirmed vulnerabilities. Starting 2025, the confirmed-rate plummeted to below 5%. Not even one in twenty was real."— Daniel Stenberg, curl

The earlier July 2025 post put numbers on the cost. The security team has seven members, and "Every report thus engages 3-4 persons. Perhaps for 30 minutes, sometimes up to an hour or three. Each." About 20% of the year's submissions were AI slop by then. The slop had been arriving for a while: among the examples he catalogued is report #2298307, filed back in December 2023 and titled "Buffer Overflow Vulnerability in WebSocket Handling." His request was modest: "We need to reduce the amount of sand in the machine."

The January 2026 post explains why the money had to go:

"We suspect the idea of getting money for [reporting] is a big part of the explanation. It brings in real reports, but makes it too easy to be annoying with little to no penalty to the user."— Daniel Stenberg, curl

HackerOne's reputation system and program settings, he added, "were not sufficient for us to prevent sand from getting into the machine."

Stenberg named three trends behind the decision: (1) "the mind-numbing AI slop," (2) "humans doing worse than ever" and (3) "the apparent will to poke holes rather than to help." So curl dropped all monetary rewards, "in an attempt to remove the incentives for submitting made up lies," stopped recommending HackerOne, pointed reporters to GitHub's private vulnerability reporting or email, and kept its policy to "immediately ban and publicly ridicule everyone who submits AI slop to the project." No prize, no incentive, and a return to unpaid coordinated disclosure.

HackerOne's cohort data, which Stenberg shared, shows curl was hit harder than most. Over four quarters its inbound volume "has risen sharply, while other bounty-paying open source programs in the cohort, such as Ruby, Node, and Rails, have not seen a meaningful increase and have remained mostly flat or declined slightly."

The Linux Kernel: Demoting Secrecy

On May 17, 2026, Linus Torvalds used the Linux 7.1-rc4 announcement to say the kernel's private security channels had become "almost entirely unmanageable." Willy Tarreau's numbers showed the private list rising from two or three reports a week two years earlier to five to ten per day by early 2026, roughly a twentyfold increase. Torvalds noted the core problem was less fabrication than duplication. Hundreds of researchers run similar LLM-guided fuzzing and static analysis against the same public tree, so dozens of identical reports about the same minor invariant violation land in the private inbox at once.

The kernel's security-bugs document now has a section called "Responsible use of AI to find bugs." It opens by noting:

"A significant fraction of bug reports submitted to the security team are actually the result of code reviews assisted by AI tools. While this can be an efficient means to find bugs in rarely explored areas, it causes an overload on maintainers, who are sometimes forced to ignore such reports due to their poor quality or accuracy."— Linux kernel documentation

Its guidance comes down to three points:

  1. AI findings go public. "If you resorted to AI assistance to identify a bug, you must treat it as public," the document says, because "bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day." Reporters should not post a reproducer. They mention that one exists and share it if maintainers ask.
  2. A tested fix is expected. Reporters are told to have their tool propose a fix and test it first, since "many AI tools are actually better at writing code than evaluating it." If the fix cannot be tested because it relies on "rare hardware or almost extinct network protocols," the issue is "likely not a security bug." A proposed fix must follow submitting-patches and carry a Fixes: tag, and "failure to consider these points exposes your report to the risk of being ignored."
  3. Describe the damage concretely. AI reports, the document says, "go to great lengths inventing theoretical consequences," and reporters should "stick to verifiable facts," such as "this bug permits any user to gain CAP_NET_ADMIN," without enumerating speculative implications. A working reproducer is expected: if it does not work, or the tool cannot produce one, "the validity of the report should be seriously questioned." Reporters should also have their tool read the kernel's threat-model document before it writes anything.

Node.js: Reputation Gating

Node.js's security team described "a significant increase in low-quality reports" that, "over the holidays," "crossed the threshold that we can actually handle." Between December 15 and January 15 it received over 30 reports, and triaging them, it wrote, "consumes time and energy that could be spent on legitimate security work."

Its answer, announced on February 19, 2026, was a HackerOne Signal requirement. "By requiring a minimum Signal score, we ensure that reporters have a proven track record of submitting valid security reports," the team wrote, while newer researchers can still take part in a limited way. Researchers without signal can no longer submit through HackerOne and are asked to contact the security team directly. Signal is HackerOne's reputation metric for the quality of a researcher's past submissions, so this gates the reporter, not the report.

The gate did not end the pressure. The OpenJS Foundation's second-quarter 2026 security update reports that submissions spiked 4.6 times once AI agent-assisted scanning tools arrived, that March alone brought 65 reports, and that on Express and Lodash 70 to 90% of what comes in is rejected. The team's next steps run in the direction this post argues for: the HackerOne template now requires reproducible examples in JavaScript, and a classifier prototyped in May has an LLM score each report against the Node.js threat model, prior accepted CVEs and weakness patterns before a person reads it.

Chromium: Absorbing the Volume

Chrome took a different route. Its security team says AI-assisted reports "are often nonsense," and even when they are not, "the vital information about the bug is buried in a pile of AI-generated words." Rather than closing the door, it drew a hard line on unproven claims, put deadlines on its own engineers' fixes and hardened the code so the reports have less to find:

"AIs will invent, and then plausibly lie about, execution traces that lead to vulnerabilities but that aren't actually possible in practice."— Chrome Security, Shepherding AI Reports

Immunefi: Banning AI Reports

Web3's main bounty platform met the problem earlier than anyone. After ChatGPT launched, Immunefi was flooded with submissions that borrowed the vocabulary of real reports and made claims that were, in its words, "nonsensical": functions that do not exist in the codebase, scrambled programming concepts, vague impact statements. Its July 2023 ChatGPT Security Report said it had not found a single real vulnerability through a ChatGPT-generated report, and such reports already accounted for 21% of its permanent bans. Founder Mitchell Amador blamed submitters "totally lacking in web3 security skills" who hoped bounty hunting would be "as easy as entering in some ChatGPT prompts."

"After ChatGPT was released, Immunefi started to receive a flood of bug reports that were very well-written, properly formatted, and used the same technical language commonly seen in successful bug reports. But upon further examination, it became clear that while the report syntax looked presentable, the underlying claims in the reports were nonsensical."— Immunefi, ChatGPT Security Report, July 2023

Immunefi's response was a rule, not a filter. Its published rules prohibit AI-generated or automated-scanner reports that lack the required information on impact to the reported asset, and violations carry suspension, a permanent ban and zero payout. For smart-contract reports, programs require a working proof of concept, typically a test that forks a local copy of the chain and demonstrates the exploit privately. Reports without one earn no reward.

That is the same lever Chromium and the kernel later reached for. I think Immunefi's head start is under-appreciated: smart contracts make the lever unusually cheap to pull, since a forked chain gives every reproducer a deterministic, sandboxed place to run, and most programs have no such luxury.

The stakes then moved from noise to capability. In June 2026 Amador said the new frontier models had shifted the playing field toward attackers and caused a "vulnerability apocalypse" behind the resurgence of DeFi hacks, while arguing that defense benefits more from AI because it is largely a scale problem of triage, monitoring and pattern recognition.

Both of his claims hold up against what this post has shown. The same models that write the slop also find real zero-days, which is why attackers gain. The defender's advantage lies in the part that scales: running every report in a sandbox, because only execution can tell a real finding from a fluent fake.

Cisco and the End of One CVE per Bug

Cisco published a policy position arguing that the principle of one CVE per vulnerability has reached its breaking point. If scanners surface thousands of minor invariant violations a week, registering, scoring and tracking each as a globally federated record does more harm than good.

Cisco's case rests on two costs. Enterprise IT teams spend thousands of hours documenting minor CVEs with no realistic path to exploitation, taking engineers away from architectural mitigations. And detailed public records for minor flaws hand adversaries a roadmap for chaining edge cases into larger exploits before enterprises can patch. Its proposal is a consolidated model: individual identifiers for high-severity zero-days, with the long tail of AI-found anomalies bundled into aggregated release notes without standalone IDs.

04 Follow the Money

Crudely speaking, bounty platforms sell human creativity at scale.

When thousands of participants can generate plausible-sounding reports in seconds, their triage queues congest and the product itself is in question.

Two Quiet Years, Then a Change a Month

The responses in this section and the last arrived in an uneven pattern. From mid-2023 to the end of 2025, the record holds a platform ban, an early curl report and one maintainer's warning. From December 2025 to July 2026, programs changed their rules or their intake about once a month. The timeline below is a curated set of the events documented in this post and does not aim for completeness.

Timeline in two panels. July 2023 to 2025: in July 2023 Immunefi says ChatGPT reports are 21 percent of permanent bans; in December 2023 curl receives report 2298307, a claimed WebSocket overflow; on July 14, 2025 Stenberg publishes Death by a Thousand Slops. December 2025 to July 2026, enlarged: Node.js receives over 30 reports between December 15 and January 15; curl ends its bug bounty on January 31; Node.js requires a HackerOne Signal on February 19; HackerOne pauses the Internet Bug Bounty on March 27; Chrome publishes an AI-generated security bugs FAQ in April; Internet Bug Bounty rates are cut on May 18; GitHub announces two tiers with cut public rewards and a Signal requirement on July 22 and 27. Colors mark reports and warnings, maintainer or vendor responses, and platform rule or payout changes.
// Figure 9. Selected program and platform responses, July 2023 to July 2026, with December 2025 onward enlarged.

Where the Money Is Going

Aggregate payouts tell a different story than the headlines. At the large corporate and crypto programs, money is still rising. Google's Vulnerability Reward Program paid just under $12 million in 2024 and "over $17 million" in 2025, "an all-time high and more than 40% increase compared to 2024." HackerOne reported $81 million paid across its platform between July 2024 and June 2025, up 13%. Immunefi's researcher payouts went from $2.40 million in the fourth quarter of 2025 to $7.87 million in the first quarter of 2026, although a single $3 million payout made up 38% of that quarter.

Three panels. Google Vulnerability Reward Program rewards per year: $12M in 2022, $10M in 2023, $11.8M in 2024 and more than $17M in 2025. Immunefi researcher payouts per quarter: $2.40M in Q4 2025 and $7.87M in Q1 2026, of which one $3M payout was 38 percent. Critical-severity reward per bug before and after cuts: Internet Bug Bounty from $9,250 to $2,257, a 76 percent cut, and GitHub's public program from $30,000 to $10,000, a 67 percent cut. Footer: curl paid $0 in rewards after January 31, 2026, and HackerOne paid $81M from July 2024 to June 2025, up 13 percent.
// Figure 10. Payouts at Google and Immunefi rising, and critical-severity rewards cut per bug at the Internet Bug Bounty and GitHub's public program.

At open-source and public programs the money is going the other way. curl has paid nothing since January 31, 2026. HackerOne paused the Internet Bug Bounty, which had funded rewards for curl and Node.js, with this explanation:

"AI-assisted research is expanding vulnerability discovery across the ecosystem, increasing both coverage and speed. The balance between findings and remediation capacity in open source has substantively shifted."— HackerOne, on pausing the Internet Bug Bounty

On May 18 it cut the program's per-bug rates by 76% to 89%, so a critical-severity payout fell from $9,250 to $2,257, according to The Register. HackerOne's spokesperson attributed the cuts to rates that "automatically adjust based on the contributions from active participating sponsors" and did not say whether AI-generated reports played a part. GitHub cut its public-program rewards in July, with critical going from $30,000 to $10,000, while keeping $30,000 and up in an invite-only tier. The restructuring was announced on July 22 and took effect on July 27, and it also required a HackerOne Signal score for the public program.

The researcher Jakub Ciolek put the underlying economics well:

"The expensive part is still very human: someone has to verify impact, deduplicate reports, decide whether something really crosses a security boundary, coordinate disclosure, and get a safe fix shipped."— Jakub Ciolek, security researcher, quoted by The Register
// where the money goes

My reading of the chart is that money is going to verified top-tier findings, and the commons that absorb the verification cost are the ones losing funding.

The Platform Response

The platforms answered with layered machine filtering, shown below. HackerOne introduced Hai Triage, an agentic pipeline that parses a submission's core claim, compares it with known duplicate clusters, checks that the cited endpoints and parameters exist within the customer's published scope and drafts a priority score before any human looks. Bugcrowd, facing an intake increase of about 500 reports a week across its managed programs, paired automated playbooks with ML models that flag language characteristic of ungrounded LLM output and deprioritize repeat low-signal submitters.

Top: traditional intake, researcher submission to a human triage specialist to the customer PSIRT. Bottom: a modern multi-tier filter stack. An inbound submission passes Tier 1, Hai triage with ML playbooks, deduplication and schema checks, which auto-rejects hallucinations and duplicates. Tier 2, an agentic sandbox that runs the report in a container, sends failures to challenge mode requesting a working proof of vulnerability. Tier 3, an expert human validator, produces a validated escalation with a patch draft.
// Figure 11. Traditional platform intake beside a three-tier machine-filtered stack.

Large enterprises built the same thing in house:

Strain on the CVE Program

The registry carries the same load as the platforms, and the strain there is measured in identifiers rather than in patches.

On July 30, 2026, the CVE Program held a Virtual Forum on AI-Enabled Vulnerability Discovery, with more than 700 delegates from 70 nations: CVE Numbering Authorities, enterprise consumers, open-source maintainers and researchers. The polling was consistent. A large majority reported significantly higher vulnerability workloads, and most named separating signal from noise as their main bottleneck. Offensive researchers reported real productivity gains from AI, but maintainers and downstream consumers said defensive automation had not reduced their manual labor.

CISA's Daniel Larson flagged the pressure on CNAs of Last Resort. Automated tools find thousands of theoretical flaws in abandoned libraries and transitive dependencies with no active security team, so CNA-LRs receive identifier requests built on incomplete, unvalidated technical claims. A workload table, labelled forum survey data, in the unsigned background analysis this post grew out of ("How Autonomous Vulnerability Discovery Shattered Bug Bounties and the Global Disclosure Ecosystem") rates triage and noise filtering an extreme increase, deduplication a sharp one, CWE root-cause mapping a moderate one because models misclassify weaknesses, with human remediation bandwidth static or declining and downstream upgrade lag growing. I could not trace those ratings to the forum's published summary, so I treat them as unverified.

Both systems are paying for the same missing step. The platforms are repricing around verification, while the registry still records claims, not proofs, and the next section is about putting the proof at the door.

05 Rebuilding the Intake

If maintainers cannot scale their attention to match machine-speed discovery, the answer has to be machines on the defensive side of the queue. The strongest evidence for that is DARPA's two-year AI Cyber Challenge (AIxCC, 2023 to 2025), which asked teams to build fully autonomous CRSs that analyze real C and Java projects derived from OSS-Fuzz, find unknown zero-days, generate proof-of-vulnerability (PoV) exploits and synthesize non-breaking patches with no human in the loop. Scoring rewarded a bundle of three artifacts: a PoV (a concrete fault-triggering input), an automated patch and a SARIF report. The bundles tell the story. Those anchored in a working PoV were right 93% of the time, against 33% for patch-and-SARIF submissions that rested on model reasoning alone, a small sample of one correct bundle in three (Zhang et al.).

The pipeline I would build from these results spends machine effort first and human effort last. Each stage either rejects, escalates or sends the report to the reporter for more evidence. My earlier post, The Algorithmic Siege, follows the same idea from the maintainer's side, with a mandatory proof-of-concept gate at the door.

Two panels. Top, left to right: a submission passes stage 1, a schema and artifact gate; stage 2, an ephemeral sandbox that builds the target with ASan, UBSan and MSan and runs the PoC in a microVM; stage 3, a defensive CRS engine that finds the root cause and drafts a patch with regression tests; stage 4, the MINT gate, which checks the finding against the project's threat model and CVE baselines; and stage 5, human sign-off. Bottom, two off-ramps: reports with a missing PoC, invalid schema or phantom code are auto-rejected at stage 1, and reports that do not reproduce in the sandbox enter challenge mode, with seven days to supply a reproducer before closing. Only reports that reproduce ever reach a maintainer.
// Figure 12. A five-stage defensive intake stack, from schema gate to human sign-off.
  1. Schema and artifact gate. Submissions must follow a machine-readable schema such as SARIF 2.1.0. A parser checks every cited file, commit and function against the current tree. Reports that reference things that do not exist are rejected with no maintainer involved, which disposes of Tier 1.
  2. Ephemeral sandbox. Surviving reports run in an isolated container or microVM. The harness checks out the target, builds it with AddressSanitizer, UndefinedBehaviorSanitizer and MemorySanitizer, and executes the supplied PoC.
  3. A forked path. A clean crash or sanitizer hit goes to a defensive CRS for root-cause localization, invariant synthesis and a candidate patch. A silent run enters automated challenge-response: an agent tells the submitter the report did not reproduce, states the test environment and allows seven days to supply a working reproducer before auto-closing. Speculative claims are filtered with no human labor.
  4. Maintainer-informed triage. The MINT gate, developed at UC Irvine, scores verified findings against the project's threat model, historical CVE baselines and trust assumptions, and condenses runtime logs into a short maintainer summary. This is where Tier 2 gets caught.
  5. Human sign-off. The maintainer sees a validated bug, a crash log and a candidate patch, and acts as architectural arbiter instead of manual tester.
// ground truth

Only dynamic execution is ground truth. Text a model wrote about code is ungrounded however fluent it is, while a sanitizer log, a concrete PoV and a regression test are facts.

That is also the insight behind Chromium's rule on reachability claims and the kernel's demand for a working reproducer and a tested fix, generalized into a pipeline. If I could keep only one stage, it would be the sandbox, for exactly that reason. I argue for execution oracles over pure AI audits in The Jagged Neurosymbolic Frontier.

The intake stack is one layer of a larger defense. The wider picture, harden, watch, contain and patch, is in Zero-Day Defense: Going from 0 to 1.

06 Incentives and Institutional Defenses

Tooling alone will not fix a broken reward structure. The root problem is that platforms pay for discovery instead of resolution. As long as a bounty goes to anyone who files a bug, cheap AI tooling will flood programs with cheap findings.

What the Bounty Economics Literature Says

Three papers on bounty economics, from 2017 and 2026, bear directly on this problem:

Maillart and colleagues studied 35 public HackerOne programs and found that the probability of finding the next bug decays roughly as t-0.4 after launch, and that the number of bugs any one researcher can find in one program is bounded. Each human brings a particular set of skills and a particular mindset, and once that angle is exhausted the next bug is much harder to reach. Researchers therefore migrate to new programs even though later bugs pay more.

The lesson was that crowds help because they are diverse, and that programs should recruit new people and feature big code changes. That premise is the one models break. Spinning up a thousand agents copies a few mindsets cheaply instead of adding new ones, and diversity turns into the duplication that swamped the kernel's security list.

The Google study (Wang et al.) is the cleanest evidence that price works on human supply. After the July 2024 increase of up to 200% for top-tier bugs, Tier 0 reports rose from 0.33 to 3.33 a month, an elasticity of 7.24, while total volume showed no definitive causal change. The raise drew a few highly productive professionals, not more participants.

// the revision

The first version, from September 2025, treated AI as a future risk. The October 2026 version restricts the main analysis to 2024 specifically to avoid AI confounds, and adds an appendix saying 2025 growth can no longer be attributed to the reward change.

It also notes that top-tier bugs tapered off in late 2025 while volume kept rising, and describes the 2025 slop wave as having loaded reviewers "to a critical degree." The authors offer their 2024 numbers as a baseline for future AI-era work, which makes the elasticity a measurement of the old regime.

Gal-Or et al. give the design rule.

// the design rule

The optimal invited set in a private program is strictly smaller than the expected number of attackers, because every extra invitee dilutes the winner-take-all payoff and lowers everyone's effort.

Curation beats breadth, and invitations should scale with the threat and with the vendor's capacity to patch, since expanding scope without matching remediation "risks clogging queues and eroding researcher incentives."

Node.js's reputation gating and the platforms' signal thresholds are this result applied by instinct. The same paper warns that AI shortens patch drafting while raising the verification and triage burden, and that a bounty program works as a post-release governance layer, not a replacement for internal assurance.

Read together, the three say the same thing. While human supply was bounded, priced rewards and curated entry kept the system in balance, because who was submitting told you something about the report. Machine supply is unbounded and anonymous, so reputation tells you little. What has to be checked is the claim itself, by running it.

Supply Shocks and Triage Costs

The doubt about paying per finding is older than the flood: Kannan and Telang raised it in 2005. Two later studies look at the problem from the supply side and the cost side.

Zrahia, Gandal, Markovich and Riordan studied what happened on Bugcrowd when COVID-19 pushed people out of work and into bounty hunting. In one year:

The extra volume was duplicates. Had demand for findings grown with supply, the authors estimate, the number of identified vulnerabilities would have more than doubled.

Two illustrated rows and a trend strip. In 2019 a few hunters send 21,157 submissions through a review funnel and 3,444 are paid; 36 percent of correct submissions earn a reward, an expected $1,520 per correct high-priority submission. In 2020 a crowd of hunters sends 53,098 submissions, with duplicates spilling past the same funnel, and 4,232 are paid; 16 percent earn a reward, an expected $629. Below, the share of correct submissions that earned a reward: 48 percent in 2017, 49 in 2018, 36 in 2019, 16 in 2020 and 37 in 2021, against submissions of 8,412, 12,527, 21,157, 53,098 and 30,955.
// Figure 13. Bugcrowd in 2019 and 2020, submissions and paid findings beside the share of correct submissions that earned a reward, with that share for 2017–2021.

The AI flood has the same shape at a larger scale, and the authors' suggested remedies, such as showing researchers a program's paid-to-valid ratio so they can see saturation, are cheap to adopt.

Zhang, Demirezen and Kumar add the cost side. In their game-theoretic model, what an organization pays after discovery, to triage, reproduce and patch, shapes the optimal reward:

The model argues for pricing the verification burden into the program, and it is the logic behind the split that pays for defense rather than discovery.

Discouraging Volume

A program can price the reward or price the attempt. Pricing the attempt is the older idea:

// pricing the submission

Pricing the submission itself has a longer history. Dwork and Naor proposed in 1992 that email carry a small proof of computational effort, so that bulk senders pay a cost the recipient can verify cheaply.

Loder, Van Alstyne and Wash proposed attention bonds: a small stake escrowed when a message is sent and forfeited if the recipient judges it a waste of time.

Immunefi's managed-triage page claims that "pay-to-submit pricing keeps spam out," and a refundable deposit on reports, returned when a report reproduces, would apply the same idea to vulnerability intake. I prefer this to a reputation gate: it asks a first-time reporter with a real finding to risk only the deposit, and it charges a bulk submitter that deposit on every report. Reputation can also be gamed, which a deposit cannot: an account can build up score on easy, low-stakes reports and spend it on a flood, a good account can be sold on, and a burned identity can be replaced with a fresh one. A deposit is paid again on every report, so there is no stored credit to farm, spend or resell.

Paying for Defense, Not Discovery

A deposit prices the submission. The larger change is to pivot payment toward verified defense. An unverified claim earns nothing. A verified PoV earns a modest base reward. The bulk of the payout arrives only with a clean, validated patch and an automated regression test that can drop into the project's CI.

The figure below shows an illustrative split of 20% for the PoV, 50% for the patch and 30% for the regression harness. Platforms should also route part of enterprise fees directly to the foundations and volunteers who do triage, since treating maintainer time as free labor for venture-backed platforms is not sustainable, and should penalize accounts that submit raw unverified LLM output with reputation loss, bans and forfeited earnings. A named person should also be accountable for every report, which is what OpenSSF's Issue #178 asks of submitters.

Comparison of reward models. Legacy: 100% of the bounty paid on report submission. Defense-aligned, illustrative: 20% for a verified PoV, 50% for a validated non-breaking patch and 30% for a regression harness in CI. Below, enterprise platform fees flow directly to open-source maintainers as triage compensation.
// Figure 14. Legacy pay-per-report rewards beside an illustrative defense-aligned split.

Shared Defense Coalitions

An individual maintainer cannot run an enterprise sandbox farm, so the industry is building shared capacity. Akrites, set up by the Linux Foundation and OpenSSF with seed funding from Alpha-Omega, places security engineers and CRS infrastructure inside vulnerable upstream projects to triage reports and draft validated fixes. Chainguard's Athena processed more than 20,000 AI-generated findings across 500 open-source repositories, filtered the synthetic noise and worked with upstream developers on over 2,000 verified patches. OpenSSF has also funded human connectors, experienced security engineers who bridge automated tools and maintainer communities and make sure AI-found bugs are disclosed with working, regression-tested code.

Two papers explain why this has to be institutional and how it might be funded. Baltes, Cheong and Treude argue that AI slop is a tragedy of the commons, in which individual productivity gains push costs onto reviewers and maintainers, and that "commons problems are not solved by individual restraint"; they ground their recommendations in Ostrom's design principles for enduring commons institutions.

On the funding side, quadratic funding (Buterin, Hitzig and Weyl, 2019) sizes a project's matching funds by the square of the sum of the square roots of what its backers give. Its largest deployment, Gitcoin Grants, reports over $60 million distributed to more than 3,700 projects. That rewards breadth of support over size of gift, which suits a security commons that thousands of small companies depend on and none will fund alone.

Liability Downstream

Regulation can make the verification problem worse before it makes it better. The EU's Cyber Resilience Act and US secure-by-design guidance put obligations on whoever ships software, and a flood of scanner findings against a public repository lands on whoever is nominally responsible for it. Imposing liability or penalties on maintainers for flaws that AI scanners find in code they give away would trigger mass abandonment of open source, and no coalition can rebuild a commons that has left.

The line has to run between commercial vendors who profit from deploying code and unpaid developers who release it under permissive licenses without warranty. Responsibility for triaging, validating and mitigating a flaw in a dependency belongs to the enterprise that shipped it inside a product, not the volunteer who wrote it. Downstream consumers should therefore build their own automated verification and triage, and fund upstream defense with engineering hours, CI compute and patch-verification resources.

Underneath the liability question sits a fairness grievance. Most of the code these models learned from was published under licenses written for human reuse, and the same model families now find and exploit bugs in that code while the report queue lands on its authors. The courts have not settled the first half. In September 2026 the Ninth Circuit affirmed the dismissal of the DMCA claim in Doe v. GitHub, which decided one statutory theory, so whether training on licensed code breaches those licenses is still unanswered. I take the legal detail apart in The Algorithmic Siege.

// the grievance, answered so far

Some projects have answered in their own rules. QEMU declines any contribution believed to include or derive from AI-generated content, citing training material of uncertain provenance and the difficulty of certifying the Developer's Certificate of Origin.

The labs' answer is money and access. Project Glasswing pairs $4M in donations with free model access for participating maintainers. Whether that settles the grievance is for maintainers to say.

07 Conclusions

Driving the marginal cost of finding bugs to near zero while the cost of triage stays put dismantled the equilibrium that protected open source and crowdsourced bounties for twenty years. Four lessons follow.

  1. Manual triage cannot scale. Maintainers and PSIRTs cannot be human filters for the internet's scanners, and asking volunteers to read faster is futile.
  2. Pay for fixes, not discoveries. Finding a bug is cheap now and fixing it safely is not, so a reward for the finding alone buys more of what is already abundant. Pay for the verified patch and the regression test that comes with it.
  3. Execution is the ground truth. Sanitizer logs, concrete PoVs and regression tests are the only evidence that holds up against fluent, ungrounded text.
  4. Cost must follow benefit. The platforms that take fees, the vendors that ship dependencies and the companies that run them should fund the verification that volunteers now carry for free.

The timeline adds a point about speed. Immunefi was banning slop reports in July 2023, and GitHub's HackerOne signal requirement took effect about three years later. The lever was known long before most programs pulled it, and once the pressure arrived the consequences chained quickly.

// the intervals

Stenberg floated dropping the money in July 2025, and the decision took about six months. curl closed its bounty on January 31, and HackerOne paused the Internet Bug Bounty, which had paid it, on March 27: 55 days.

The Internet Bug Bounty cut its rates 52 days after the pause, on May 18, and GitHub's two-tier program took effect 70 days after that, on July 27.

The responses split in two directions. curl and the Internet Bug Bounty pulled money back, while Chrome kept its program open and put clocks on its own engineers' fixes. My reading is that the difference owes less to report volume, since curl's volume rose faster than Ruby's, Node's or Rails' in HackerOne's cohort data, than to who is paid to do the verifying: the load that ended an unpaid maintainer's bounty was a staffing problem at Google. The timeline is a curated list with nothing in June, so "about once a month" describes a pattern, not a rate.

Two numbers carry the argument. In DARPA's AI Cyber Challenge, bundles anchored in a working proof of vulnerability were right 93% of the time, against 33% for model reasoning alone, which is why every production gate converged on the same test: a reproducer from Immunefi and Chromium, a tested fix from the kernel.

The pressure is not a funding collapse. Google's program paid over $17 million in 2025, an all-time high, and HackerOne moved $81 million across its platform in a year. What is being repriced is the cost of proving a finding, and that cost has always been human.

The likely end state is a co-evolution of offensive and defensive autonomous systems, not a contest between humans and machines: models probing software continuously while defensive engines synthesize patches and check invariants in sandboxes before code ships, and human engineers setting security boundaries and arbitrating intent. That end state is not here yet. The intake stack is still a proposal, and triage still runs on human attention.

I think getting there depends on building the verified, execution-grounded intake layer before the queues fully collapse, and on deciding who pays for it: the platform that takes a fee, the vendor that ships the dependency, or the coalition the commons builds in its place.

References

curl
Other open-source projects
The Linux kernel
Chromium and Node.js
Immunefi and Web3
Bounty platforms and payouts
Corporate programs and autonomous hunters
The CVE program
Time to exploit
Discovery systems
DARPA's AI Cyber Challenge
Patch quality, supply chain and end-of-life software
History of bug bounties
Bounty economics
Pricing submissions and funding the commons
Law and regulation
Standards and policy