The number of vulnerabilities being found in releases of the Linux kernel is continuing to skyrocket, an issue that has emerged over the past two years and which has coincided with the improving capabilities in AI models to detect them.
Most recently, the tech media and benchmarking site Phoronix reported that Greg Kroah-Hartman, a Fellow at The Linux Foundation and a Linux stable maintainer, shared a slide for an upcoming presentation at the Kernel Recipes 2026 conference in Paris later this month that showed the number of CVEs fixed per kernel release is closing in on 2,000 as Linux 7.3 approaches.
It’s a startling number, given that for many of the releases in the Linux 6.x era, it hovered around 500. It surpassed 1,000 CVEs with Linux 7.0 and pushed well past 1,500 with 7.2. The trend has continued sharply upward since.
It’s not necessarily an indication that the Linux kernel is becoming less secure with each passing release. Instead, it’s likely the result in large part of large language models (LLMs) becoming more adept at finding security flaws in the kernel.
“The codebase itself hasn’t grown to match” the sharp increases in CVEs found and fixed, developer Karthick Palanisamy wrote on LinkedIn. “It’s still roughly 34 million lines of C, growing the way large mature codebases always grow incrementally, not explosively. What changed isn’t the kernel. It’s who’s reading it.”
AI-Assisted Tools and Frontier Models
The estimates of the lines of code in the Linux kernel vary – some reports put it at more than 40 million lines – but the argument is the same: More people are using AI to find bugs in the kernel. Palanisamy pointed to a time in July when the kernel security team published 432 CVEs over 24 hours.
“AI-assisted tools are now scanning kernel code at a scale no human review process was ever built for,” he wrote. “The result is old, obscure driver code some of it untouched for years suddenly surfacing bugs nobody had looked closely at before.”
The rise of frontier AI models like Anthropic’s Mythos, OpenAI’s GPT-5.6 Sol, and others that have hit the scene in recent months have shown advanced capabilities in detecting vulnerabilities, including some that have gone undiscovered for more than a decade. They’re also highly capable of quickly developing exploits, which has forced the AI vendors to carefully parse who has access to them.
Unearthing the Real Threats
While the use of AI to find bugs in the kernel is a key contributor to the flood of new CVEs, it isn’t the only one, which means maintainers will continue to be overwhelmed by the volume. That “is exactly why the way we consume it has to change,” Dvir Sasson, vice president of AI and security research at Zest Security, wrote in a blog post.
Organizations and security teams need to look beyond just the number of security flaws and their severity scores to find which represent real threats, said Sasson, whose company offers an agentic AI platform that automates how security and DevOps teams prioritize and fix vulnerabilities in software and the cloud.
“None of that is going to slow down, and the part that turns this volume into working attacks is getting cheaper by the month,” he wrote. “This is worth being clear-eyed about, because the shape of the next two years is already visible in the last two.”
Kernel Gains Numbering Authority
The number of CVEs started to climb after the kernel became its own CVE Numbering Authority in February 2024, according to Palanisamy and Sasson.
“The kernel team now issues CVEs directly under its own criteria rather than relying on outside reporting,” Palanisamy wrote. “Part of the ‘surge’ is better accounting of a category of bug that always existed but wasn’t consistently being counted before.”
The reasoning behind the move was sound, Sasson wrote, saying that “maintainers cannot know which quiet bug turns exploitable in a configuration they have never seen, so they stopped guessing and started disclosing all of it.” Some of the vulnerabilities being surfaced date back many years and have never been exploited.
Needed ‘Evidence Behind the Scream’
Looking at the environments Zest monitors, about one in seven open findings are from Linux kernel CVEs, and about 56% of those come with a “high” or “critical” label from the scanner that detected them. When seeing whether any of the findings are being exploited – checking against CISA’s Known Exploited list or with an Exploit Prediction Scoring System (EPSS) probability – it comes out to about a quarter of a percent.
“More than half the queue screams Critical; fewer than one finding in four hundred has evidence behind the scream,” Sasson wrote.
The situation will get more difficult, he wrote. Along with the CVE numbering system, the volume of CVEs being added to the list will bury those already there, many of which remain open for years.
It Won’t Get Easier
“When this week’s batch is loud enough, last year’s is invisible, and the year before that is geological,” Sasson wrote. “The inflow is rising and the backlog is compounding at the same time, which is the definition of a problem that gets worse on its own.”
That said, it does come back to AI. Turning a flaw into a working exploit in the past was complex and time-consuming and outpaced what humans can do. “The flood was survivable because the flood was unreadable,” he wrote.
That’s changed with Mythos and other frontier models that can not only spin up exploits quickly but also do so cheaply. Bad actors also can use such models.
“The same deep review that helps maintainers find these bugs reads them just as well from the other side, for pennies per million tokens, with nobody watching,” Sasson wrote. “That is what ‘gets worse’ means in practice.”