In recent weeks, alarm bells have been ringing repeatedly over critical vulnerabilities in the Linux kernel. Why is that? Do we have AI to thank for these discoveries? And should we expect similar incidents in short order?
The four kernel vulnerabilities are characterized by the fact that they can only be exploited if an attacker has already gained access through other means. Furthermore, they are not memory safety errors—normally the most common vulnerabilities—but rather relate to errors in the fundamental logic of the kernel’s operation.
Three of a kind, and one outlier
Copy Fail and Dirty Frag, in particular, have received a lot of publicity, partly because Fragnesia and ssh-keysign-pwn were only discovered very recently. The first two vulnerabilities have also already been exploited “in the wild,” creating a high sense of urgency to apply patches to the affected Linux distributions.
There is another distinction between the vulnerabilities. Copy Fail (CVE-2026-31431) exposed a conceptual flaw in the operation of the Linux kernel, specifically the cryptographic subsystem. A single Python script, just 732 bytes in size, is enough to lead to an exploit. As Palo Alto Networks’ Unit 42 explains, this allows a malicious actor to escape from Kubernetes containers, compromise multi-tenant hosts, and infiltrate CI/CD pipelines.
More broadly, Copy Fail turned out to expose a logic flaw in the Linux kernel. This led to the discovery of Dirty Frag, where a single script can also lead to privilege escalation. Here, two vulnerabilities (CVE-2026-43284 and CVE-2026-43500) worked together to exploit vulnerable components related to the network and memory. A new variant soon followed after organizations had just implemented their mitigations and patches: Fragnesia. In this case (CVE-2026-46300), a different bug is capable of exploiting Linux’s page cache behavior to escalate privileges. Whereas Dirty Frag wreaked havoc in rxrpc, here the esp/xfrm module is the attack vector.
The exception to the rule is the newly discovered ssh-keysign-pwn. Unlike the bugs mentioned above, it is unrelated to the page cache. Instead, an attacker can use this exploit to read root-owned files, such as SSH host keys. The pidfd_getfd() system call is exploited to steal descriptors from setuid binaries. In other words: a fundamentally different bug than the previous three, but due to the commotion surrounding the other vulnerabilities, it is receiving more attention than a typical, incidental discovery of a Linux kernel bug would have received.
Essentially a single flaw, but a crucial one
There is a commonly held belief that the open-source world would, in principle, produce safer software. This belief is fairly justified. With closed-source applications, users, researchers, and developers cannot simply know what code is running. Even tools that can translate the binary code back to assembly and then provide an idea of the original code are conceptually limited. It is by no means certain that the code generated from this process corresponds to the original code. Instead, it is an educated guess.
Even with low-level languages like C, in which the Linux kernel is primarily written, the reproducibility of the original source remains uncertain to the point of being completely unreliable. As a result, logic errors cannot simply be reverse-engineered from generic applications. But with open-source, that opportunity does exist, because the original code is accessible. Whether dealing with logic errors or memory overflow issues, they can often be explained simply by pointing out the flaw in the written lines of code.
That approach is paying off now as well. Even though some vulnerabilities were years old (and therefore possibly already being secretly exploited), they have since been discovered, reported, mitigated, and mostly patched. That’s not to say the reporting process went smoothly all the time. For example, the linux-distros mailing list was not informed about Copy Fail before the kernel security team was already aware of it and had applied a silent patch, to the frustration of some. Subsequently, the discoverer of Dirty Frag was forced to rush the disclosure of the exploit because a third party had already deciphered the silent commit.
Given the high frequency of reported, serious flaws, such friction is disastrous. Communication within the open-source community will need to be faster to prevent exploits or at least reduce their success rate.
Does AI play a role?
Some may ask: did AI play a role here? There are plenty of stories circulating about the security capabilities of Claude Mythos and OpenAI’s GPT-5.5-Cyber, with potentially massive implications for the number of vulnerabilities that will be discovered on a regular basis. Nevertheless, there isn’t yet a major wave of AI-driven exploits. At least, as far as we can tell. Only in the case of Fragnesia does the discoverer mention a find made using the “dangerously powerful agentic security” tool V12. Exploit generation via this tool is thus said to be more complex than the old ML-based “pattern matching” process. Nevertheless, Fragnesia is a successor to a vulnerability discovered by human researchers, namely Dirty Frag.
After all, the errors themselves are (still) human-made. For now, AI tools seem to have raised the security level of the Linux kernel, which is a good thing. That does not change the fact that there is a real risk that AI-driven errors will gradually be introduced into software. It is not very realistic to assume that the Linux kernel will act decisively in this area; unlike the developers of simple, vibe-coded applications, the maintainer team of this critical foundation for the operating system cannot afford to make mistakes. At any rate, humans do make mistakes, and these incidents simply show how true that is.
Incidentally, we are experiencing a downpour of Linux vulnerabilities, not just this quartet of ‘drops’. The rapid succession of cyber threats gives the impression that more are on the way. Regardless, the number of discovered vulnerabilities already broke records last year, meaning we should have been wearing our raincoats for a while. 50,000 CVEs were recorded in 2025, a 22 percent increase compared to the previous year. Specifically regarding the Linux kernel, TuxCare already spoke of a “flood” of CVEs in early 2025. In the first 16 days of that year alone, more of them were reported within the Linux kernel than in the entirety of 2020.
Yet, it is the four kernel vulnerabilities mentioned above that most strikingly demonstrate how the Linux kernel is increasingly found to contain ever more serious flaws. It is important to remember that these are discovered cyber threats; the number of reported CVEs coming in is now higher than ever, but the actual volume of vulnerabilities in the code itself has potentially decreased, precisely because they are being reported and addressed.
Read also: Linux vulnerability Dirty Frag affects nearly all distributions