AI-Driven Fraud Is Undermining Trust in Bug Bounty Programs
What began as a collaborative win-win—rewarding independent researchers for uncovering real security flaws—has taken a troubling turn. Bug bounty platforms are now being exploited by a new wave of AI-powered deception.
A growing number of submissions, nicknamed “AI slop” by insiders, aren’t uncovering vulnerabilities—they’re fabricating them. These bogus reports, often written with the help of large language models (LLMs), mimic the language of authentic security disclosures so convincingly that some have even slipped through and earned payouts.
The implications are serious. These synthetic reports can easily mislead triage teams, especially at organizations without deep security expertise. The content often looks professional on the surface—complete with jargon, references to CVE-like threats, and even suggested fixes—but collapses under expert review. Beneath the polish, they cite imaginary functions and describe scenarios that can’t be reproduced.
Security researchers at Socket.dev have flagged this as a growing concern for open-source projects and smaller organizations. With limited internal capacity for deep technical review, many teams are forced to choose between spending valuable time verifying each report—or paying out to avoid the appearance of negligence.
A prominent example occurred with the curl project. A report submitted through HackerOne, later identified as H1#3125832, falsely described a vulnerability using fabricated function names and unverifiable patches. The curl maintainers quickly recognized it as AI-generated noise. The individual behind the hoax, linked to the @evilginx account, had reportedly succeeded with similar tactics elsewhere.
Harry Sintonen, a seasoned researcher, summed it up plainly:
“The attacker miscalculated badly. Curl can smell AI slop from miles away.”
How to Spot a Synthetic Vulnerability Report
Deceptive reports often follow a pattern. They name-drop plausible but non-existent functions—like the fabricated ngtcp2_http3_handle_priority_frame in the curl example. When challenged, the submitter typically dodges by referencing arbitrary old versions or inventing commit hashes.
These submissions are designed to look right but not be right. They tend to omit detailed steps to reproduce the issue, making validation difficult. By weaving real security concepts into fictional implementations, the attacker creates just enough noise to confuse under-resourced teams.
This kind of misuse strikes at a weak point in the system: initial triage. Many teams don’t have the bandwidth to deeply analyze each incoming report, especially when it appears credible.
Seth Larson, Security Developer-in-Residence at the Python Software Foundation, has observed the mounting toll:
“In the age of LLMs, these reports seem valid on first read—and that illusion consumes time we don’t have.”
As the line blurs between genuine and generated, organizations need better tooling, sharper triage, and collective vigilance to prevent AI from turning good-faith security efforts into a battlefield of misinformation.
