AI slop floods bug bounties: open source sets boundaries

What this is about

Open-source maintainers have increasingly received security reports since 2025 that were clearly or likely produced with AI tools. On May 17, 2026, Linus Torvalds wrote in the publicly linked LKML post that the Linux security list had become almost unmanageable because of duplicate and weakly checked AI findings. Help Net Security covered the issue on May 18, 2026 and connected it with GitHub’s new bug bounty rules.

The core issue is uncomfortable: AI can find real vulnerabilities. But when people forward outputs without checking them, a new kind of security noise appears. Volunteer maintainers, security teams and bug bounty programs lose time on reports that show no reproducible exploitation, no concrete impact and often no real understanding of the code.

What AI slop in security reports actually does

An AI-assisted security report often starts with a scanner, an LLM or a combination of both. The tool finds suspicious patterns, turns them into a plausible vulnerability description and sometimes produces long explanations that sound professional. That is the risk: the text looks competent even when the finding has not been validated.

In rules published on May 15, 2026, GitHub describes three minimum requirements: a working proof of concept, a clear connection to program scope and manual validation before submission. OpenSSF is collecting best practices in parallel because open-source projects are especially exposed. They often do not have paid triage teams, only a few people who also handle releases, support and real security issues.

Why it matters

Security reports are valuable only when they improve scarce attention. If a project receives ten real vulnerabilities and one hundred AI hallucinations, the result is not more security but congestion. Curl ended its bug bounty program at the end of January 2026 and pointed to sharply falling hit rates: Daniel Stenberg wrote that in 2025 the confirmed vulnerability rate dropped below five percent.

This also matters for companies. Many software supply chains depend on volunteer-maintained libraries. If maintainers burn out because of AI spam or see legitimate reports later, every user of those components carries more risk. This is not an abstract debate about tool ethics; it is a capacity problem in security infrastructure.

In plain language

Imagine a fire department dispatch center. A useful call says: there is a fire on street X, third floor, here is a photo, here is the caller’s number. AI slop is closer to one hundred calls saying: maybe something smells like smoke somewhere, I saw it in an app. Even if one call is accidentally correct, dispatchers still have to check every single one.

Open source faces the same pattern. Maintainers need precise, verifiable reports. Long automatically written texts without a test case are not help; they are extra work.

A practical example

A small open-source project receives 40 security reports over a weekend. Eight claim remote code execution, but none includes a working exploit. Twelve report known configuration items that are out of scope. Fifteen contain almost identical AI-written explanations of theoretical risks.

If a maintainer spends only 20 minutes per report, that is more than 13 hours of triage. In the same time she could review two real patches, update a dependency or prepare a release. For a company using that library in 10,000 installations, the difference is direct: less noise means faster response to real vulnerabilities.

Scope and limits

First, AI is not the enemy. GitHub explicitly says AI is welcome in security research when humans reproduce the result and prove impact.

Second, not every short or poorly written report is worthless. Some real finders write briefly, some do not write perfect English, and maintainers should not confuse quality with polished style.

Third, there is no reliable technical detector for AI-generated reports. OpenSSF describes detection itself as difficult. That is why blanket AI bans are weak; stronger requirements work better: reproducible test case, scope check, impact statement and concise evidence.

SEO & GEO keywords

AI slop, AI security reports, bug bounty, open source security, Linux Kernel, Linus Torvalds, GitHub Security Lab, OpenSSF, HackerOne, curl, vulnerability disclosure, proof of concept