It's raining kernel CVEs, and it's gonna get worse

The Linux kernel is the single largest source of CVEs in the world. Not the largest operating system. The largest anything. A screenshot went around this month showing 432 kernel CVEs published in twenty-four hours, and the top reply just said "must be Tuesday." Our own feed logged 441 in the last seven days. Most arrived with no severity score and no exploitation data at all. Nobody had been attacked.

None of that is going to slow down, and the part that turns this volume into working attacks is getting cheaper by the month. So this is worth being clear-eyed about, because the shape of the next two years is already visible in the last two.

The rain is deliberate, and permanent

In February 2024 the kernel became its own CVE Numbering Authority and started assigning an ID to nearly every bugfix that reaches a stable release. The reasoning is sound. 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. Greg Kroah-Hartman, who runs the stable tree, has said he needs to drop his old line about the kernel being the number two source of CVEs, because it is number one now by a wide margin, and he means it as a point of pride.

He is right to. More eyes are on the code everything else runs on. The same month as this kernel batch, nginx patched a heap overflow in its regex engine, CVE-2026-42533, reachable by one unauthenticated request and rated as high as 9.2. Last month it was seven OpenSSL bugs at once. Much of that review is now machine-assisted: Google's Big Sleep found a live SQLite bug that attackers already knew about, before anyone shipped a public exploit. This is the system working. It is also not going to get quieter, which is exactly why the way we consume it has to change.

The numbers say the volume is still climbing. Before the CNA change, the kernel was credited with a few hundred to at most fifteen hundred CVEs a year, depending on whose count you trust. In 2024, the first full year under the new policy, it cleared three thousand (3,108 by one tally, 3,529 by another). The first half of 2026 already carried more than 2,300, ahead of Chrome and roughly triple Microsoft. Our own feed shows the same curve from inside real environments: the count roughly tripled the year the policy flipped and has stayed there.

Why it gets worse, part one: the scoring comes apart

Volume alone is survivable. Volume plus meaningless severity is not, and the severity is getting less meaningful every year.

Across the environments we monitor, kernel CVEs are about one in seven of every open finding in the queue. Around 56% of them carry a High or Critical label from the scanner that surfaced them. Check those same findings against whether the bug is being exploited anywhere, on CISA's Known Exploited catalog or with a real EPSS probability, and the share with genuine signal behind it is about a quarter of one percent. More than half the queue screams Critical; fewer than one finding in four hundred has evidence behind the scream.

That gap is widening, not closing. The scoring feeds we ingest tagged 174 kernel CVEs at CVSS 9.0 or higher in the first half of 2026 alone, against 32 across the entire five years from 2021 through 2025. A study this year measured the same decay from the other side and found the CVSS score barely predicts how quickly the kernel team itself bothers to fix a bug. The label is becoming a coin flip with a red badge on it.

Why it gets worse, part two: the old debt never clears

The flood does not just add to the queue, it buries what is already in it. In our data, open kernel CVEs reach all the way back to 2019. Bugs disclosed, scored, and fixed upstream six years ago are still sitting open in production today. When this week's batch is loud enough, last year's is invisible, and the year before that is geological. 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.

Why it gets worse, part three: exploitation got cheap

For years the volume was accidental armor. A kernel CVE is one line of description and a patch. Turning that into a working exploit is slow specialist work, and at three thousand a year, nobody could do it at the rate they land. The flood was survivable because the flood was unreadable.

That is the assumption that just broke, and here are the numbers. Anthropic's own red team tested a restricted model, Claude Mythos, against 21 real Windows kernel privilege-escalation CVEs, giving it only public patches and advisories. It produced eight full working privilege-escalation chains at roughly $2,000 of compute each, and its first crash landed in 31 minutes. The model generation before it, released only months earlier, produced zero completed chains. On a separate Firefox set, the same model wrote its first working exploit in under an hour and eight in about twelve. This is the slow specialist step, done overnight, and it improved that much in a single release cycle.

Anthropic keeps Mythos behind a trusted-access program and monitors how it is used, which is the responsible way to ship a capability like this. The gate is the problem, because it does not travel with the capability. Two weeks ago Moonshot released Kimi K3 as open weights, near the frontier on code, and Alibaba previewed Qwen 3.8. Open weights mean no gate: you run the model on your own hardware and no vendor sees the prompt or enforces a policy.

That is not hypothetical either. On July 19, the reverse engineer behind OALabs posted a screenshot of Claude killing a reverse-engineering session mid-run, an acceptable-use block that told him to apply for a verification program to continue. His writeup, "Kimi K3 Reverse Engineering: Opus Without The Nagging," describes moving the work to Kimi K3, the open Chinese model, because it runs the same code without the refusals. His takeaway: it "makes us question why we are paying Anthropic."

A working professional switched to an ungated model precisely because it reads the code without asking why. 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. That is what "gets worse" means in practice.

The honest part: most of these are local

Before the panic sets in, the correction that most coverage skips. The large majority of kernel CVEs are local. They need an attacker who is already on the machine, and they hand over root once there. That is serious in shared, containerized, and multi-tenant environments, and it is not the remote, internet-facing disaster a red Critical badge implies. The remote ones exist and they are ugly, but they almost always require you to have switched on a network-facing kernel service you could have left off. The distance between how a kernel bug reads on a dashboard and what it takes to actually fire is the distance that wastes your week.

The five that earn the label

If you want the kernel bugs worth real attention, do not sort by CVSS. Sort by whether anyone is using them.

• CVE-2022-0847, "Dirty Pipe." A missing initialization in the pipe buffer let any local user overwrite files they should only be able to read, root-owned ones included. On CISA's exploited list, EPSS near 89%. Local, and trivial. fix commit
• CVE-2024-1086. A use-after-free in netfilter's nf_tables, the current default answer to "get me root on this box." Public exploit, real-world use, KEV-listed with known ransomware use. Local. fix commit
• CVE-2022-0492. A cgroups flaw that lets a process climb out of its container onto the host as root under ordinary settings. CISA re-added it to the exploited catalog this June, so it is current, not history. Local, but a container escape, which in a Kubernetes fleet is the whole game. fix commit
• CVE-2023-0386. An OverlayFS bug that carries setuid capabilities across user namespaces to reach root. OverlayFS is the filesystem under most container images, which is why this one traveled. KEV-listed. Local. fix commit
• CVE-2022-47939. A use-after-free in ksmbd, the kernel's built-in SMB server. CVSS 9.8, and the exception to everything above, because it is remote. It only bites if you exposed an in-kernel SMB service you probably never needed. That is the shape of remote kernel bugs: rare, severe, and self-inflicted. fix commit

Four local, one remote. That ratio is the whole argument for prioritizing by what a bug actually requires instead of what it scores.

Worth seeing how small these fixes are. Here is the entire Dirty Pipe patch, the one that closed a universal local-root exploit:

‍

- buf->ops = &page_cache_pipe_buf_ops;

+ buf->flags = 0;

‍

One line. The field was left uninitialized, so a fresh pipe buffer inherited stale permission flags from recycled memory, and that was enough to overwrite any file on the system. Commit 9d2231c5, February 2022. A one-line bug that scored a 7.8 and earned a name.

‍

What to do while it gets worse

Patching faster will not save you, because the inflow already moves faster than any patch cycle and the exploitation cost is falling underneath it. The move is to stop treating the queue as a list to burn down and start treating it as exposure to prioritize. This is what continuous threat exposure management (CTEM) is for.

Three steps carry most of the load. Rank by reachability before severity: most kernel CVEs a scanner flags inside a container image cannot be exploited there at all, because the container borrows the host's kernel and never boots its own, and that single check clears a large slice of the one-in-seven. Sort what survives by exploitation instead of CVSS, because KEV status and EPSS are what pull the one-in-four-hundred that is real out of the pile. Then fix at the source by rebuilding on a patched kernel image, so the whole fleet clears in one wave instead of one ticket at a time, which is exactly the repetitive, verifiable work that agentic remediation handles well.

How Zest helps

This is the problem we built Zest for. We take everything your scanners flag and funnel it down to the few that can actually be reached in your environment and are actually being used.

The scanner hands you thousands of CVEs a year. We hand you the handful worth someone's afternoon. That is the difference between a queue and an answer.

It is raining kernel CVEs, the volume is climbing, and the cost of turning any given drop into a working exploit is dropping toward zero. Both of those trends are going to continue. The teams that treat this as an exposure-management problem, and prioritize by reachability and real-world exploitation, will be fine. The teams still sorting by CVSS are going to spend the next two years drowning in criticals that were never going to be used, while the handful that mattered walk in the door.

Sources. Kernel CNA: CVE.org, kroah.com, kernel.org docs. Severity vs reality: arXiv 2601.22196. AI exploit generation: Anthropic n-days, Claude Mythos, Project Glasswing. Open models: Kimi K3, Chinese-model red-teaming. The five fixes link to their upstream commits on git.kernel.org. Fleet figures are aggregated and anonymized across the environments we monitor.

‍