AI Slop Is Turning Bug Bounty Programs Into A Security Liability
Ido Geffen, CEO and Co-founder, Novee Security.
gettyBug bounty programs have traditionally relied on human researchers to identify cybersecurity vulnerabilities, with submission volumes that security teams could generally manage.
There were always strong reports and weak ones, but the weaker submissions were often easy to spot. They were thin, poorly written or obviously misunderstood the environment, so an experienced analyst could simply reject them quickly.
AI is changing both the volume of reports and how easily teams can distinguish legitimate findings from noise. A bad report today might look carefully analyzed, technically plausible and full of detail—and still be wrong. The “AI slop” phenomenon is not limited to creative disciplines such as writing and design. It’s all too rampant in cybersecurity as well.
That can make things expensive. Analysts now have to take more time to investigate—reading the report, reproducing the claimed issue, understanding it in the context of the application, assessing whether it’s actually exploitable and deciding where it belongs against other risks—before discovering that there’s nothing there. A researcher can file a report in minutes, while the team receiving it pays in hours.
HackerOne reported in May 2026 that the industry experienced a 100%-plus surge in report volume after more advanced AI models and tools arrived in February. The new volume includes valuable findings alongside duplicates, unverifiable submissions and reports lacking enough depth to act on.
Bug bounty programs were designed around human researcher attention as the scarce resource. AI is changing where that scarcity sits.
In January 2026, Daniel Stenberg, a maintainer of curl, a widely used open-source data-transfer tool, ended the project’s monetary bug bounty after what he described as an explosion of AI-slop reports. The share of submissions that became confirmed vulnerabilities had fallen from above 15% historically to below 5% in 2025. Stenberg specifically cited the time required to debunk bad reports.
By April, curl had returned to HackerOne as its reporting platform while keeping monetary rewards eliminated. Stenberg reported that submission volume was running at roughly double the already elevated 2025 rate, but quality had improved substantially: Roughly 15% to 16% of reports were again becoming confirmed vulnerabilities, and he believed AI was involved in almost every submission to varying degrees.
curl’s experience also shows that AI can improve vulnerability research. The deeper problem is economic. The cost of generating a plausible hypothesis has fallen, while the cost of proving whether it represents real risk remains high.
And the capacity problem didn’t disappear when quality improved. curl subsequently stopped accepting vulnerability reports for the entire month of July to give maintainers relief from the workload. Once discovery runs continuously and automatically, scarcity moves somewhere else.
You might look at a growing queue and see an efficiency problem. I see a security problem.
When teams can’t quickly discern irrelevant findings from important ones, every hour an expert spends disproving plausible noise is time they aren’t spending investigating or remediating real exposure.
That pressure compounds because the people doing the sorting are often the people with the deepest application knowledge. They are the ones who can reproduce a finding, understand whether it conflicts with the system’s intended design, and judge whether it creates a real attack path. As queues grow, their expertise gets pulled into triage instead of remediation.
The polished nature of AI-generated submissions can make the problem worse. A weak report that looks credible takes longer to reject, while a legitimate vulnerability may sit behind it in the same queue.
Triage latency is just dwell time you’ve handed to an adversary.
A finding without a working demonstration is a hypothesis, and hypotheses can be generated by the thousands now.
The evidentiary threshold has to evolve with the cost of producing a report. Programs should put more weight on evidence that a finding can be reproduced and tied to real impact:
• Reproducibility: Can the researcher reliably reproduce the behavior?
• Demonstrated Impact: What can an attacker actually accomplish?
• Context: Does the finding account for how the application actually works, including permissions, architecture and business logic?
Raising the bar too bluntly could discourage legitimate researchers or incentivize people to cause actual damage merely to prove that an exploit works. The goal is to demand better evidence without encouraging researchers to cause harm in order to prove a point.
That could mean clearly defining what constitutes acceptable reproduction, giving researchers safe testing boundaries/environments where appropriate, and distinguishing a serious disclosure that lacks a complete exploit chain from mass-produced speculative findings.
AI has increased the potential to create noise, but it also lets more people examine more software, and capable researchers can potentially work faster. Now the question is whether the incentive structure rewards researchers for producing the kind of evidence defenders can actually use.
Bug bounties historically rewarded discovery because skilled human attention was expensive and limited. As AI-assisted and eventually autonomous discovery becomes more common, discovery itself accounts for less of the scarce value in the process. What remains scarce is proof, context and a verified fix.
That suggests the unit of value may change over time. Bounty structures could place more weight on demonstrated exploitability, useful remediation and confirmation that the risk has actually been closed. The programs that hold up best will be the ones that reward evidence and risk reduction, not just report volume.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
