Information securityArtificial intelligence

1,313 CVEs in one go: is AI breaking the Linux security model?

6 October 2026

Debian’s release of a Linux kernel update with a list of vulnerabilities almost as long as a small book has reignited a debate that goes well beyond Linux. The problem is not just that more bugs are being found today. It is that artificial intelligence is making vulnerability hunting so cheap and scalable that it calls into question the very way the security industry catalogs, assesses and fixes them.

The advisory that started the debate

The case that set off the discussion is Debian advisory DSA-6528-1, published on 29 September 2026 for the kernel of Debian 13 “trixie”. The text is terse: several vulnerabilities that may lead to privilege escalation, denial of service or information leaks, and a recommendation to upgrade the kernel.

Jan Schaumann, security researcher and Chief Information Security Architect at Akamai, then counted the identifiers listed in the advisory: 1,313 CVEs. In a message to the oss-security mailing list he argued that an advisory like this no longer serves any concrete purpose, and that for anyone defending complex systems it is becoming unrealistic to keep reviewing and assessing every vulnerability one by one.

The number, however, should be read with care. The Linux kernel deliberately follows a very cautious CVE assignment policy. Because the kernel runs at the most privileged level of the system, an apparently harmless bug can, under certain conditions, turn into a security problem. That is why the kernel documentation openly states that the team assigns a CVE to practically every bug fix it identifies, even when real exploitability is limited to very specific configurations. It is one of the most debated points in the long Hacker News thread: counting CVEs is not automatically the same as measuring how insecure a system is.

Torvalds: the problem is not AI, it is how the results arrive

One of the most important voices is that of Linus Torvalds, creator of Linux and lead kernel developer. Back in May 2026, in a release candidate announcement, Torvalds wrote that the flow of vulnerabilities found with AI tools had made the kernel’s private security mailing list “almost entirely unmanageable”. The issue, for him, was not that AI was finding bugs. It was the way those results reached the maintainers: different people used the same tools, found the same problems and sent duplicate reports, adding nothing on top, neither an analysis nor a patch. His invitation was explicit: if you want to contribute, read the documentation, write the fix too, and add real value on top of what the AI did.

Torvalds’ position is therefore far less hostile to artificial intelligence than one might think. In July he made clear that Linux “is not one of those anti-AI projects” and that he has no intention of stopping anyone from using LLMs. Responsibility, however, stays human, which is the line the kernel’s rules have drawn: a result produced by a machine only becomes useful when someone understands it, verifies it and takes technical responsibility for it.

Kroah-Hartman: 79 vulnerabilities, about ten real fixes

Even more interesting is the position of Greg Kroah-Hartman, Linux Foundation Fellow and in charge of the stable kernel releases, one of the people who actually ship the fixes that end up on Linux systems all over the world.

At Kernel Recipes 2026 in Paris, Kroah-Hartman examined a heavily publicized case: the 79 kernel vulnerabilities that Anthropic announced it had found with its Mythos model. Looked at one by one, the picture became much less spectacular. Twenty-four reports lacked sufficient detail, fourteen were not bugs, three contained made-up data and fifteen concerned problems that had already been fixed. In the end, by his assessment, the truly significant fixes were about ten.

This does not mean Kroah-Hartman considers artificial intelligence useless. On the contrary, he describes these tools as a very good form of static analysis, precisely because they work by recognizing recurring patterns in code. The problem arises when the machine’s output is treated as a conclusion rather than as the starting point of an investigation. In an experiment in which LLM-generated security patches were reviewed by PhD students, about half of those that looked convincing turned out to be wrong, useless or aimed at problems that did not exist. For kernel maintainers the risk is obvious: automating vulnerability discovery without automating their verification with the same reliability means dumping huge amounts of work on human beings.

Stenberg and curl: swamped, but not against it

A similar view, seen from a completely different project, comes from Daniel Stenberg, founder and lead developer of curl and libcurl, one of the most widely used open source components in the world. Stenberg has long been very critical of automatically generated, unverified security reports. In January 2026 curl shut down its bug bounty program after the team had been swamped by low-quality AI-generated reports.

But his position is also more nuanced than a simple rejection. In May he explained that automated tools such as AISLE, ZeroPath and OpenAI’s Codex Security had led, in less than a year, to a few hundred bug fixes in curl, and that a good dozen of them had become CVEs. The project also uses AI for code review. For Stenberg these tools help human reviewers, but they do not replace them. So the problem is not artificial intelligence as such, but the fact that producing a convincing report costs almost nothing, while verifying it still takes time and very expensive skills.

Ptacek: do not bet against LLMs

On the other side of the debate there is a particularly significant voice, that of Thomas Ptacek, veteran software security researcher and cofounder of Matasano Security, a firm that was for years one of the big names in vulnerability research. Ptacek warns against underestimating what is happening. In his view vulnerability research may be the software engineering problem best suited to LLMs: it is driven by pattern recognition, has a huge corpus of public examples and makes it possible to check quickly whether an attempt works or not. His position is essentially the opposite of those who dismiss the recent discoveries as marketing: “do not bet against LLMs on this”.

What is happening in smaller projects

The Hacker News thread also offers an interesting look at what happens far from the kernel. Thomas Boutell, cofounder of Apostrophe and the instigator of the effort that produced the PNG format, says that the much smaller open source project he leads had for months been getting at least six responsibly reported security advisories a month, while last month it received twenty-two. His summary is spot on: software is hard and AI is thorough. His team still manages to keep up by using artificial intelligence in turn, together with human review. But the imbalance is clear: the number of people, and machines, that can hunt for vulnerabilities in a project can grow almost without limit, while the number of maintainers able to understand and fix them does not grow at the same pace.

In the same discussion William Woodruff, open source maintainer involved in projects such as Homebrew and Sigstore and author of software supply chain security tools, describes another effect of the current system: many companies have a “risk management system” that consists of nagging open source projects to do free work for them, even when the advisory is manifestly nonsense or has no impact in context. It is the “green dot” mindset on the dashboard, which CVEs encourage by stapling a CVSS score to every identifier. The risk is turning security into a race to silence alerts instead of a concrete assessment of exposure.

The end of vulnerability scarcity

Put these opinions together and a less sensational picture emerges, but probably a more important one than the figure of 1,313 CVEs. The people who work directly on the kernel and on the big open source projects do not doubt that artificial intelligence can find real vulnerabilities. In fact, many of them are already using it for exactly that. The problem is that finding a possible bug is becoming much cheaper than establishing whether it is really dangerous.

For decades the security model treated the discovery of a vulnerability as a relatively rare event. A researcher found a problem, someone analyzed it, a CVE was assigned, a patch was prepared and administrators decided how quickly to apply it. That system works much less well when millions of lines of code can be analyzed continuously by thousands of automated agents.

The real change brought by AI may therefore not be a sudden increase in software insecurity. It may be the end of the scarcity of known vulnerabilities.

When finding a potential problem costs almost nothing, value moves elsewhere: understanding which vulnerabilities are really exploitable, fixing them without introducing new bugs, shipping updates quickly and designing systems in which a single flaw has limited consequences.

This is where the views of Torvalds, Kroah-Hartman, Stenberg, Ptacek and the others seem to converge, despite their differences. Artificial intelligence does not remove human work from information security. At least for now it is doing almost the opposite: it produces so much information that human judgment, knowledge of the system and the ability to tell a real risk from noise become even more valuable.

The more you pay, the more you see

There is, however, one aspect of this story that worries me more than the number of CVEs.

The tools that find vulnerabilities at scale today are not free. They run on paid frontier models, and their effectiveness grows with how much you are willing to spend: more tokens, more agents in parallel, more compute time, more code analyzed. Those with a budget can sift through millions of lines every day; those without one have to make do with much less.

Unfortunately all of this is introducing a model of poor democratization of technology. The more you pay, the more capability you have. If you do not pay, you simply do not have enough capability to compete: neither to find the bugs in your own software before someone else does, nor to defend yourself from those who can afford to look for them in yours.

For a large company it is a cost item. For a volunteer maintainer, a small open source project or a small business it is a gap that risks becoming structural. The same people who today receive, for free, the reports produced by other people’s machines are often the ones who cannot afford the same machines to verify them.

I see only one realistic way out, and it goes through hardware. If hardware for local inference keeps becoming more accessible, and if the weights of open source models keep improving, one day we will be able to have local LLMs powerful enough to make us independent from frontier models. At that point the ability to analyze your own code will no longer depend on a subscription or an API budget, but on a machine you own.

Until that day, security risks becoming one more thing you buy, rather than something you know how to do.