AI made finding bugs cheap. Fixing them is now the bottleneck

The discovery cost collapsed

Finding a plausible vulnerability used to take skill, time and a working understanding of a codebase. Large language models have removed most of that cost. Researchers and automated tools can now generate large volumes of candidate reports against popular open-source projects in hours. The problem is that the work does not end with discovery. Someone still has to reproduce the issue, judge its severity, write a fix, review it, and ship it to users. None of those steps got cheaper.

That asymmetry is now forcing bug bounty programs to change their rules. curl suspended its bug bounty in January 2026. Google tightened its open-source reward program in March 2026, requiring higher-quality proof, such as an OSS-Fuzz reproduction or a merged patch, for certain payout tiers. Google has said that many AI-generated submissions include hallucinated trigger conditions or report bugs with little real security impact. In April, HackerOne paused Internet Bug Bounty payouts. The program had paid out more than $1.5 million since 2012 and historically allocated about 80 percent of rewards to new findings and 20 percent to remediation support.

HackerOne's explanation is the clearest statement of the problem so far. It said that AI-assisted research is expanding vulnerability discovery across the ecosystem, increasing both coverage and speed, and that the balance between findings and remediation capacity in open source has substantively shifted. Node.js, one of the first affected projects, continues to accept reports through HackerOne but no longer pays rewards for them.

Why bad reports are expensive

A wrong report is not free to the people receiving it. A maintainer has to read it, reproduce it, and explain why it fails, often in a thread full of polite but unhelpful back-and-forth. If the report describes a trigger path that does not exist, the maintainer may spend hours investigating code that is never reached. Multiply that by dozens of submissions and a volunteer team can lose its entire week to triage. Reports that look authoritative but are wrong are more expensive than obviously bad ones, because they cannot be dismissed at a glance.

The response from programs has been to move the evidence burden back onto the reporter. Asking for a fuzzer reproduction, a proof of concept that runs against the current release, or a patch makes the reporter do part of the work the maintainer would otherwise do. It also filters out submissions where the author has not actually run the code.

Why this matters beyond open source

The stakes are not theoretical. Verizon's 2026 Data Breach Investigations Report found that about 31 percent of breaches now originate from exploitation of software vulnerabilities, up from about 20 percent the year before. Vulnerability exploitation has overtaken stolen credentials as the leading initial access route in that dataset. Most enterprise software is built on open-source components, so a backlog in upstream remediation becomes a backlog in every downstream product.

Coverage of the funding gap has also highlighted the scale of the problem. The Linux Foundation reportedly sought financial help from AI companies, and Google, Anthropic, AWS, Microsoft and OpenAI together committed $12.5 million toward open-source security work, according to reports. That is a meaningful sum, but it is a one-time contribution compared with the ongoing labour of maintaining widely used libraries.

What should change

The right move is to pay for the expensive part of the work. Discovery is now cheap; a confirmed fix that ships is not. Several changes follow from that.

• Maintainers should write an explicit evidence bar into their security policy. Reports without a reproduction, a failing test or a proof of concept can be closed automatically, with a short template explaining what is needed. This takes a few minutes to set up and saves many hours later.
• Maintainers should treat patch review as a budgeted activity. If a project depends on volunteers, the funding should cover review time, not only bounty payouts for reports.
• Companies that depend on open-source software should measure time to fix, not time to report. A security team that tracks how many issues it has triaged will optimise for volume. A team that tracks how long a vulnerability stays unpatched in its dependencies will fund the work that matters.
• Bounty platforms should pay more for merged fixes than for reports, and should consider paying for reproduction artefacts before triage starts.
• Researchers who find real bugs should submit patches alongside reports. A patch that passes the test suite is the single most useful thing a reporter can hand a maintainer.

What this means for your own team

If you run a product that depends on open-source components, start with an inventory of which upstream projects you rely on and whether they have an active security response process. Ask your vendors for their patch service levels, not only their scan results. When a vulnerability is reported upstream, the time to a fixed release is the number that determines your exposure, and that number depends on maintainer capacity you can help fund.

The discovery problem is not going away, and it probably should not. More bugs being found is not a failure in itself. The failure would be to keep rewarding the cheap step while the expensive step falls on a few exhausted volunteers. The programs changing their rules now are trying to correct that, and the teams that depend on the software should be paying attention too.