From Scarcity to Flood: How AI Vulnerability Reports Forced Linux to Rewrite Its Security Rules
1. "Almost Entirely Unmanageable"
Sunday, May 17, 2026. An unusual email appeared on the Linux Kernel Mailing List (LKML).
The sender was Linus Torvalds. In his routine announcement of Linux 7.1-rc4, he spent considerable space on something unrelated to code: the private security mailing list had become "almost entirely unmanageable."
> "The continued flood of AI reports has basically made the security list almost entirely unmanageable, with enormous duplication due to different people finding the same things with the same tools." > > — Linus Torvalds, Linux Kernel Mailing List, 2026-05-17
The complaint was not about how many vulnerabilities AI found. It was about the same people using the same tools finding the same bugs, then dumping dozens of duplicate reports into the same private list.
Maintainers' time was being exhausted—not fixing vulnerabilities, but forwarding emails and replying "this was fixed last week." In Torvalds's words: "People spend all their time just forwarding things to the right people or saying 'that was already fixed a week/month ago.'"
He called it "entirely pointless churn."
2. This Didn't Happen Overnight
To understand the weight of this email, look at what happened over the past two years.
August 2024: DARPA held the first AI Cyber Challenge. AI systems not only found deliberately planted bugs but also discovered over a dozen previously unknown real vulnerabilities. At the time, the industry was still discussing the "potential of AI-assisted auditing."
January 2026: The curl project—the command-line tool used on virtually every connected device—shut down its HackerOne bounty program. The reason was identical: a flood of low-quality AI reports. Maintainer Daniel Stenberg said they were spending too much time dealing with "auto-generated nonsense."
April 7, 2026: Anthropic released the 244-page System Card for Claude Mythos Preview. During testing, this model autonomously discovered thousands of zero-day vulnerabilities across all major operating systems and browsers. Some landmark findings:
- A 27-year-old OpenBSD remote crash vulnerability—in an OS that bills itself as the most secure, having survived 1,000 automated tests and countless human reviews
- A 17-year-old FreeBSD RCE (CVE-2026-4747), yielding unauthenticated remote root access
- A 16-year-old FFmpeg vulnerability missed by 5 million test runs
- 181 exploitable bugs in Firefox 147—a 90x increase over the previous model Opus 4.6's 2
- Reports must be concise, plain text, and focused on verifiable impact
- Must include reproducible test cases
- Ideally, include a patch
- From "private disclosure" to "public tracking" (eliminating duplication)
- From "reporting bugs" to "submitting patches" (raising signal-to-noise ratio)
- From "human discovery" to "human + AI collaboration" (redefining the participation bar)
- Linus Torvalds, Linux Kernel Mailing List, 2026-05-17
- Tom's Hardware, "Linus Torvalds says AI bug reports have made Linux security mailing list almost entirely unmanageable", 2026-05-18
- Cybersecurity News, "Linus Torvalds on AI Bug Reports", 2026-05-18
- The Register, "Linus Torvalds says AI-powered bug hunters have made Linux security mailing list almost entirely unmanageable", 2026-05-17
- Anthropic, "Project Glasswing: Securing critical software for the AI era", 2026-04-07
- Anthropic Frontier Red Team, Claude Mythos Preview System Card, 2026
- MindStudio AI Blog, "AI Cybersecurity in 2026: How Claude Mythos and GPT 5.5 Are Finding Zero-Day Exploits", 2026-05-16
- Cyber Defense Magazine, "When AI Stops Assisting And Starts Discovering", 2026-05-07
Anthropic security researcher Nicholas Carlini made a widely quoted remark: he found more vulnerabilities in weeks with Mythos than in his entire career.
But the truly frightening part of these numbers isn't "how many were found"—it's "how many can't be fixed." Anthropic itself disclosed: over 99% of the vulnerabilities remained unpatched at the time of publication.
The industry coined a name for it: "Patchpocalypse."
3. The Private List Paradox
The most counterintuitive point in Torvalds's email: he wasn't calling for more secrecy—he was calling for less.
Traditionally, private disclosure of security vulnerabilities has been industry standard practice. It gives maintainers time to patch before details go public, preventing malicious exploitation. The process assumes: vulnerabilities are scarce information worth protecting.
But AI changed a fundamental premise: AI-discovered vulnerabilities are not secrets.
Torvalds put it bluntly:
> "AI-detected bugs are pretty much by definition not secret, and treating them on some private list is a waste of time for everybody involved — and only makes that duplication worse because the reporters can't even see each other's reports."
The logic is simple: if anyone can scan the same open-source code with the same open-source AI tools, then "who found it first" carries no informational advantage. The private list's only effect was to keep reporters from seeing each other's submissions—everyone believed they were the first discoverer.
In the AI era, secrecy mechanisms create information silos.
4. The Community's Pragmatic Counterattack
The Linux community did not ban AI tools. Instead, they took a pragmatic path: rewriting the rules.
The updated security-bugs documentation, merged alongside 7.1-rc4, boils down to a few core points:
1. Distinguish "real security vulnerabilities" from "ordinary bugs mislabeled as security issues"
The document states plainly: "The majority of the bugs reported via the security team are just regular bugs that have been improperly qualified as security bugs due to a lack of awareness of the Linux kernel's threat model." Most bugs submitted through the security team were ordinary bugs mislabeled because reporters didn't understand the kernel's threat model.
2. AI-discovered bugs go through public channels by default
"Bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day." Since they aren't secrets, they follow the public process.
3. Significantly raised quality bar
Torvalds's summary is blunter:
> "If you found a bug using AI tools, the chances are somebody else found it too. If you actually want to add value, read the documentation, create a patch too, and add some real value on top of what the AI did. Don't be the drive-by 'send a random report with no real understanding' kind of person."
In translation: Don't be an AI mouthpiece—be an AI partner.
4. The "Assisted-by" tag
The Linux kernel's Developer Certificate of Origin (DCO) process was also adjusted. AI-assisted patches must be explicitly tagged "Assisted-by"—not a mark of shame, but a transparency statement. Patches submitted by Greg Kroah-Hartman using his locally built AI system "Clanker T1000" did exactly this: the AI found the issue, the patch was written, verified by the human, submitted openly, and tagged as AI-assisted.
It's a closed loop. Not the one-way relay of "AI finds → human relays," but a collaboration chain of "AI finds → human understands → human fixes → human takes responsibility."
5. Two Philosophies Compared
Facing the same flood, different communities chose different responses.
| Community | Approach | Essence | |------|------|------| | curl | Shut down HackerOne bounty program | Cut off the entry point | | Linux | Raise the bar + change the process | Rebuild the rules | | Anthropic | Project Glasswing ($100M / 11 closed-door partners) | Centralized control |
curl chose to close the door—when maintainer time costs exceed vulnerability value, the economic equation no longer holds.
Anthropic chose a walled garden—Mythos is not publicly released, available only behind closed doors to 11 large companies (AWS, Apple, Microsoft, Google, etc.) and the Linux Foundation, with a $1 million donation to open-source security organizations. This is the "too powerful to release" approach.
Linux chose a third path: don't ban AI, but require quality of participation. Torvalds's attitude is clear—"AI tools are great, but only if they actually help, rather than cause unnecessary pain and pointless make-believe work."
All three choices make sense, depending on what you're protecting. curl protects its maintainers' limited energy. Anthropic protects against the model's dangers. Linux protects the possibility of open collaboration.
6. From Scarcity to Flood: The Real Paradigm Shift
The deeper meaning of this story isn't "how powerful AI is," but a fundamental shift in the economics of information.
In the manual-audit era, vulnerability information was scarce. Finding one required substantial expert time, so every discovery carried informational value worth keeping confidential.
In the AI-scanning era, vulnerability information is abundant. The scarce resource is no longer "discovery capability" but "repair capability." When discovery speed grows exponentially while repair speed remains linear, the entire process must be redesigned.
The Linux community's new documentation is exactly that redesign attempt:
This is not an AI vs. human confrontation. It is humans redefining their role at machine speed.
7. Epilogue: Surf, or Build Walls?
Back to the end of that email. Torvalds didn't say "don't use AI"; he said "use them in a way that is productive."
There's no standard answer to this question. curl built a wall, Anthropic built a garden, and Linux chose to learn to surf.
But one trend is clear: CVE issuance in March 2026 exploded compared with the same period in prior years. Security reports have turned from "scarce goods" into "a flood." When AI can both create and discover vulnerabilities, the open-source world's choice isn't "whether to allow AI," but "does human judgment still have value at machine speed?"
The Linux community's answer is pragmatic: it does—but only if you do more than press a button and feel like you're contributing. You must understand what you're submitting, and ideally you can also fix it.
This is not an idealist's manifesto. It's a pragmatic course correction by an open-source project running for over thirty years, trying to turn the ship toward a new channel before the flood hits.
*References:*