From Scarcity to Flood: How AI Vulnerability Reports Are Forcing Linux to Rewrite Its Security Rules
1. "Almost Entirely Unmanageable"
On Sunday, May 17, 2026, an unusual email appeared on the Linux Kernel Mailing List (LKML).
The sender was Linus Torvalds. In his routine update announcing Linux 7.1-rc4, he devoted significant space to 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
His complaint was not about how many vulnerabilities AI found. It was that the same people, using the same tools, found the same vulnerabilities — then dumped dozens of duplicate reports into the same private list.
Maintainers' time was being consumed — not fixing bugs, but forwarding emails and replying "this was already fixed last week." As Linus put it: "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 previous two years.
August 2024: DARPA held the first AI Cyber Challenge. AI systems not only found deliberately planted bugs but also surfaced 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 present on nearly every internet-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 handling "auto-generated nonsense."
April 7, 2026: Anthropic released the System Card for Claude Mythos Preview — 244 pages. During testing, the model autonomously discovered thousands of zero-day vulnerabilities across all major operating systems and browsers. Landmark findings included:
- A 27-year-old OpenBSD remote crash bug — in an OS that brands itself the most secure in the industry, which had 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 bug that 5 million tests failed to detect
- 181 working exploits in Firefox 147 — versus 2 from the previous-generation Opus 4.6, a 90x jump
- Reports must be concise, plain-text, and focused on verifiable impact
- They must include reproducible test cases
- Ideally, they come with a patch
- From "private disclosure" to "public tracking" (eliminating duplication)
- From "reporting bugs" to "submitting patches" (raising signal-to-noise)
- From "human discovery" to "human + AI collaboration" (redefining the bar for participation)
- 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: within weeks, Mythos had found more vulnerabilities than he had in his entire career.
But the truly alarming part of these numbers is not "how many were found" — it's "how many can't be fixed." Anthropic itself disclosed that over 99% of the vulnerabilities remained unpatched at publication.
The industry coined a name for it: "Patchpocalypse."
---
3. The Paradox of the Private List
The most counterintuitive point in Linus'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. Maintainders get time to prepare patches, then details are published, preventing malicious exploitation. This process rests on an assumption: vulnerabilities are scarce information that must be protected.
AI changed a fundamental premise: AI-discovered vulnerabilities are not secrets.
Linus was direct:
> "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, "who found it first" carries no informational advantage. The only thing a private list accomplishes is making reporters unable to see each other's submissions — everyone believes they're the first to discover something.
In the AI era, secrecy mechanisms create information silos.
---
4. The Community's Pragmatic Counterattack
The Linux community did not ban AI tools. Instead, it chose a more pragmatic path: redefining 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 documentation 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 are ordinary bugs mislabeled because reporters don't understand the kernel's threat model.
2. AI-discovered bugs default to public channels
"Bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day." If they aren't secrets, they follow the public process.
3. Quality gates raised significantly
Linus's summary was 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 other words: don't be AI's mouthpiece — be AI's partner.
4. The "Assisted-by" tag
The Linux kernel's Developer Certificate of Origin (DCO) process was also adjusted. AI-assisted patches must be clearly tagged "Assisted-by" — not a badge of shame, but a transparency declaration. Patches submitted by Greg Kroah-Hartman using his locally built AI system "Clanker T1000" did exactly this: find the issue, write the patch, verify it himself, submit publicly, and disclose AI assistance.
That's a closed loop. Not a one-way "AI finds → human relays" pipeline, but a collaborative 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 the HackerOne bounty program | Cut off the inflow | | Linux | Raise the bar + change the process | Rewrite the rules | | Anthropic | Project Glasswing ($100M / 11 closed-door partners) | Centralized control |
curl chose to close the door — when the maintainer's time cost exceeds the value of a vulnerability, the economic equation no longer holds.
Anthropic chose a walled garden — Mythos was not publicly released, made available only to 11 major companies (AWS, Apple, Microsoft, Google, etc.) and the Linux Foundation, with a $1 million donation to open-source security organizations. The logic: "too capable to release."
Linux chose a third path: don't ban AI, but demand quality of participation. Linus was 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 maintainers' limited energy. Anthropic protects against model dangerousness. Linux protects the possibility of open collaboration.
---
6. From Scarcity to Flood: The Real Paradigm Shift
The deeper meaning of this story is not "how powerful AI is" but a fundamental shift in information economics.
In the era of manual auditing, vulnerability information was scarce. Finding one required substantial expert time, so every discovery had informational value worth protecting.
In the era of AI scanning, vulnerability information is abundant. The scarce resource is no longer "discovery capability" — it's "repair capability." When discovery grows exponentially while repair remains linear, the entire process must be redesigned.
Linux's new documentation is exactly that redesign:
This is not AI vs. humans. It's how humans redefine their role at machine speed.
---
7. Epilogue: Surf, or Build Walls?
Back to the end of that email. Linus did not 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, Linux chose to learn to surf.
One trend is clear: CVE issuances in March 2026 exploded relative to prior years. Security reports went from "scarce goods" to "flood." When AI can both create and find vulnerabilities, the open-source world's choice is not "whether to use AI" but "whether human judgment still has value at machine speed."
The Linux community's answer is pragmatic: yes — provided you don't think you're contributing just by pressing a button. You must understand what you're submitting, and ideally you can fix it.
This is not an idealist manifesto. It's a 30-plus-year-old open-source project making a pragmatic course correction before the flood swamps the boat.
---
*References:*
*Also published on zhichai.net.*