An attacker who lands on a Linux box as an ordinary user wants one thing next, and that is root. Elastic Security Labs has been keeping count of how they get it, and its latest tally has an uncomfortable shape: seven of the thirteen Linux privilege escalation CVEs the team tracked in 2026 are the same bug, pointed at different parts of the kernel.
That is not thirteen problems. It is closer to one problem and a list of places to aim it.
The same mistake, a dozen doors
The class Elastic describes is a copy-on-write or zero-copy path that writes into data it was supposed to copy first. Copy Fail opened the run in April 2026, and we covered it when a working exploit put root within reach of any logged-in user. DirtyFrag, Fragnesia, DirtyDecrypt and DirtyClone pushed the identical idea through ESP, RxRPC and the socket-buffer fragment helpers within weeks, and one of them sent vendors checking whether their own appliances were exposed. pedit COW moved it into traffic control. RefluXFS took it back to the filesystem in July.
Elastic is careful about how much weight those numbers carry. Neither its count of thirteen nor its count of seven is a census, and the team says to read them as a picture of how the work changed rather than as a tally of every kernel escalation bug. The pattern is the claim, not the arithmetic.
Why the same idea kept landing
Part of the answer, by the researchers' own account, is that finding the next instance got cheaper. Qualys attributes RefluXFS to a research effort with Anthropic that pointed Claude Mythos Preview at the kernel's memory management and filesystem code to hunt for a DirtyCOW-style race, then reproduced and verified the result before disclosure. The author of OVSwrap, the Open vSwitch flaw that handed local users root across most mainstream distributions in August, credits a comparable workflow. Humans stayed on validation and disclosure in both cases.
Elastic does not claim language models are the whole story, and says they are unlikely to be the only factor. What the two write-ups do show is the loop itself: hand a model a known bug class, ask it for a new instance, repeat. When one idea can be aimed at a dozen kernel interfaces inside a single quarter, the old rhythm of reading each advisory and writing a rule for that technique stops keeping pace. A detection written per CVE is a detection that arrives after the CVE.
Detect the outcome, not the exploit
Elastic's answer, set out by Ruben Groenewoud, is to stop matching on the trigger and start matching on what every escalation has to produce. Whatever the underlying bug, the skeleton on the host is the same: an unprivileged user runs something from a directory they can write to, such as /tmp, /dev/shm, /var/tmp or a home directory, and moments later a process in that lineage is running as root. Plenty of proof-of-concept code then confirms it by calling whoami or id.
That gives two layers. A general layer keyed on the outcome and its immediate context, which reaches bug classes nobody has seen yet because it depends on no exploit-specific artifact, and a per-class layer that adds signal for known patterns, such as a setuid helper like su, sudo, pkexec or passwd running with an effective user ID of 0 while the real user is not root, launched with unusually few arguments from an interpreter or a writable path. Elastic maps that case to ATT&CK technique T1548.001 and publishes the rules in its detection-rules and protections-artifacts repositories.
The team is blunt about the limits. The framework is built on the public proof-of-concept for each flaw, a PoC can be reshaped to sidestep a specific match, and Elastic makes no claim to catch every Linux escalation, least of all one built to evade these rules. The full write-up, with the rule logic, is on Elastic Security Labs.
If the cost of finding the next instance of a bug class keeps falling, the rules worth writing are the ones that never needed to know which instance it was.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.