Stenberg removed the money, not the machines

Daniel Stenberg shut down curl's bug bounty because of what the money was attracting, not because of what was writing the reports. On 31 January 2026 he ended a programme that had run since April 2019, had confirmed 87 real vulnerabilities and had paid out over USD 100,000. The reason was a collapse in the hit rate. Before 2024, north of 15 percent of submissions turned out to be genuine security issues. Through 2025 that fell below 5 percent, which as Stenberg put it meant not even one in twenty was real. A volunteer team of seven was spending hours debunking each one, work he described as taking a serious mental toll.

His own explanation of the decision is worth reading precisely. "The main goal with shutting down the bounty is to remove the incentive for people to submit crap and non-well researched reports to us," he wrote. Notice what that sentence does not say. It does not name a technology, and it does not propose to detect one. It identifies a payout as the thing selecting for bad work, and removes the payout. His standard for reporters is equally tool-agnostic: you should never report a vulnerability unless you actually understand it and can reproduce it.

Volume doubled and the hit rate tripled

The result went the opposite way to the obvious prediction. Stopping payment did not empty the queue. By April 2026, after curl had returned to unpaid reporting, submissions were arriving at roughly twice the 2025 rate, and 15 to 16 percent of them were confirmed as real vulnerabilities. The count of confirmed findings passed where it had been in 2024, before the flood started.

The detail that matters most is the one that sounds like a contradiction. Nearly every report still appeared to be AI-assisted. What changed was that most of them were now good. "The slop situation is not a problem anymore," Stenberg reported in April. The tool did not leave the queue. The slop did.

Read as a control problem, the bounty had been a filter pointed at the wrong target. A cash award for an accepted finding pays out on submission volume multiplied by luck, so it rewards sending quickly and hopefully rather than verifying first. That pressure existed before generative models and was merely survivable; cheap generation made it fatal. The scale is visible elsewhere too. Bugcrowd saw report volumes more than quadruple over three weeks in March. HackerOne recorded a 76 percent year-on-year jump in submissions through March, though on that platform the share flagging real vulnerabilities held steady at about 25 percent, which is a useful check on the idea that every queue collapsed at once.

Nobody actually banned anything

The one census that counted the field found zero outright bans. A fully enumerated survey of 53 disclosure programmes, covering four coordination platforms, 20 vendors and 29 open-source projects, was retrieved on 28 July 2026. Not one of them prohibits AI-written bug reports outright. The widely repeated claim that the industry has banned them describes a policy that no programme in the sample has actually written down.

The real distribution is less dramatic and more useful. Thirty-six programmes, 67.9 percent, say nothing about AI in their published policies at all. Sixteen, 30.2 percent, address it with conditions. Among those sixteen, thirteen require human verification of a finding, eleven require a working reproduction, eight refuse submissions that are purely autonomous while still permitting AI assistance, and three require the reporter to disclose that AI was used: Intigriti, Django and FFmpeg. Human verification, not prohibition, is the convergent standard.

The census also found a defect worth copying down. Three programmes published their AI rules somewhere other than their main policy page. A condition the reporter never saw and never agreed to is not a condition you can enforce against them, which turns a written rule into decoration. The programmes that changed status did not ban anything either: curl closed its bounty in January 2026, Nextcloud suspended paid rewards in April, and the Internet Bug Bounty paused submissions.

Apple and GitHub went after the person

Apple's guidelines now attach the penalty to the reporter's standing rather than to the report. Apple states plainly that it receives many reports claiming to be about serious security or privacy issues "that are generated by LLMs and submitted without the required proof or validation by a person." Its remedy is a pause. If a researcher repeatedly submits ineligible reports, including infeasible ones about theoretical issues or those discovered by AI without proper validation, Apple may pause processing their reports for 180 days. More than two paused periods and the researcher may be permanently removed from the programme.

The second half of that penalty is the sharper one. While paused, a researcher is ineligible not only for payment but for credit in security advisories, and for a professional security researcher public credit is the durable currency. Apple's terms of service reach the same place from another direction, barring a consistent, repeated or high-volume pattern of submitting spam or false claims, "such as reports generated by or with the assistance of AI that are not validated by human review." The operative words are the last five. The clause does not prohibit the assistance, it prohibits shipping the output unchecked.

GitHub took the other identity route, splitting the programme in two with effect from 27 July 2026. Public awards were cut to USD 250 for a low-severity finding, USD 2,000 for medium, USD 5,000 for high and USD 10,000 for critical, down from USD 500 to 1,000, USD 5,000, USD 20,000 and USD 30,000 respectively. The old rates now live in an invite-only tier paying USD 1,000, USD 7,500, USD 20,000 and USD 30,000 or more, and entry requires a demonstrated record: one accepted critical finding, or two high, or four medium, or seven low. New reporters on the public programme face a signal requirement with up to four initial submissions to prove themselves. The stated aim, from product security engineer Catherine Cassell, is reducing the noise so the team can focus on the signal.

The reporter you throttle may be the one who matters

Reputation gating carries a cost that none of these announcements prices. Every one of these designs rewards an existing track record, which is a sound way to rank people who report often. But the person who finds one critical flaw in your product, having never filed a report anywhere before, is by definition the profile with no record at all, and that is the report you least want throttled. GitHub's answer is four submissions to establish signal. Apple's is a status that can be paused for half a year. Both are defensible; neither is free, and the cost lands on exactly the one-time finder whose single report may be the most valuable one you receive this year.

For a European manufacturer this stops being a question of philosophy on 11 September 2026, when the reporting obligations of the Cyber Resilience Act start to apply. A manufacturer that becomes aware that a vulnerability in its product is being actively exploited must notify ENISA and the relevant national CSIRT within 24 hours, provide a fuller assessment within 72 hours, and file a final report within 14 days of a corrective measure being available. The Act also requires a coordinated vulnerability disclosure policy: a structured route by which someone can tell you, so you can fix the problem before the details reach the public. Read the deadline carefully and the intake problem becomes a compliance problem. The clock starts when you become aware, and a queue buried in unvalidated reports is a machine for delaying awareness.

Three things follow for anyone running that intake. Require a working reproduction and say so on the page the reporter agrees to, because a reproduction is provable and a claim about which tool wrote the text is not. Fix the incentive before you write a rule, since curl's queue improved when the payout stopped rather than when a policy changed. And measure the confirmed-finding rate rather than the report count, because volume is the number that went up in the one case where everything got better. Nothing in the Cyber Resilience Act requires you to pay a single reporter. It requires you to be reachable, and to be able to tell a real report from a plausible one fast enough to start the clock on time.