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 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 wasn't about how many vulnerabilities AI had found. It was about the same people using the same tools finding the same vulnerabilities, then dumping dozens of duplicate reports into the same private list.
Maintainers' time was being exhausted—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 hosted the first AI Cyber Challenge. AI systems not only found intentionally 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 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 long. The model had autonomously discovered thousands of zero-day vulnerabilities across all major operating systems and browsers during testing. Some landmark findings:
- A 27-year-old OpenBSD remote crash vulnerability—in an OS that bills itself as the most secure in the industry, having survived 1,000 automated test runs and countless human reviews
- A 17-year-old FreeBSD RCE (CVE-2026-4747), enabling unauthenticated remote root access
- A 16-year-old FFmpeg vulnerability missed by 5 million test runs
- 181 exploitable bugs in Firefox 147—versus 2 for the previous-generation model Opus 4.6, a 90x improvement
- 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 now-frequently-quoted remark: the vulnerabilities he found with Mythos in a few weeks exceeded everything he'd found in his entire career.
But the truly frightening part of these numbers isn't "how much was found"—it's "unfixable." Anthropic itself disclosed: over 99% of the vulnerabilities remained unpatched at the time of publication.
The industry gave it a name: "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. It gives maintainers time to prepare patches before details go public, preventing malicious exploitation. The process rests on a core assumption: vulnerability information is scarce and needs protecting.
But AI changed a fundamental premise: AI-discovered vulnerabilities are not secrets.
Linus was blunt:
> "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" no longer carries any informational advantage. The private list's only real effect was to make reporters invisible to each other—everyone assumed they were the first discoverer.
In the AI era, secrecy mechanisms create information silos.
4. The Community's Pragmatic Counterattack
The Linux community didn't ban AI tools. Instead, they chose a more pragmatic path: rewriting the rules.
The updated security-bugs document merged alongside 7.1-rc4 boils down to a few key 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 default to public channels
"Bugs discovered this way systematically surface simultaneously across multiple researchers, often on the same day." Since these bugs are found by multiple researchers on the same day—they aren't secrets, so they go through the public process.
3. Dramatically raised quality bar
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 megaphone—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 as a mark of shame, but as a transparency declaration. Patches submitted by Greg Kroah-Hartman using his locally built AI system "Clanker T1000" did exactly this: find the problem, write the patch, verify it himself, submit publicly, tag AI assistance.
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 the HackerOne bounty | Cut off the intake | | Linux | Raise the bar + change the process | Rebuild the rules | | Anthropic | Project Glasswing ($100M / 11 closed partnerships) | Centralized control |
curl chose to close the door—when maintainers' time cost exceeds a vulnerability's value, the economic equation no longer holds.
Anthropic chose to build a walled garden—Mythos is not publicly released, available only behind closed doors to 11 major 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 demand quality participation. Linus's attitude 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 the model's dangerousness. 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"—it's a fundamental shift in information economics.
In the era of manual auditing, vulnerability information was scarce. Finding one required massive expert time, so every discovery carried informational value and was worth keeping confidential.
In the era of AI scanning, vulnerability information is abundant. The scarce resource is no longer "discovery capability" but "fix capability." When discovery speed grows exponentially while fix speed remains linear, the entire process must be redesigned.
The Linux community's new document is one attempt at that redesign:
This isn't AI vs. humans. It's how humans redefine their role at machine speed.
7. Epilogue: Surfing, or Building Walls?
Back to the end of that email. Linus 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 issuances in March 2026 exploded compared to the same period in prior years. Security reports have gone from "scarce goods" to "a flood." When AI can both create and discover vulnerabilities, the open-source world's choice isn't "whether to allow AI"—it's "whether human judgment still has value at machine speed."
The Linux community's answer is pragmatic: yes, it does—but only if you don't think pressing a button counts as contributing. You must understand what you're submitting, and ideally, fix it too.
This isn't an idealistic manifesto. It's a pragmatic course correction by an open-source project that has run for over thirty years, trying to turn the rudder toward a new channel before the flood arrives.
---
*References:*