SURIQ
A file-integrity monitor that reports every binary on your Linux box as unchanged can be telling the truth and still be hiding a root compromise. That is the uncomfortable lesson from a run of kernel privilege-escalation bugs disclosed since April, two of which got public working exploits in the last two weeks. Each one rewrites a privileged program like /usr/bin/su in memory, never on disk. The inode never changes, the checksum still matches, and an unprivileged local user is now root. These are not five unrelated bugs. They are one design flaw wearing five names.
A clean integrity check now means nothing
The newest of these, nicknamed DirtyClone and filed as CVE-2026-43503, turns the kernel's packet-cloning machinery into a write primitive. It carries a CVSS score of 8.8. When Linux duplicates a network buffer, two internal helpers, __pskb_copy_fclone() and skb_shift(), forget to carry over a bit that says those bytes still belong to a real file. With that marker gone, the kernel treats a page of an on-disk program as scratch space it is free to edit. An attacker maps a setuid program such as /usr/bin/su, steers it through a loopback IPsec tunnel they configured, and the decryption pass scribbles bytes of their choosing over the binary while it sits in the page cache. JFrog Security Research, which released a full proof-of-concept on June 25, 2026, stated the result bluntly: nothing on disk moves, so file-integrity tools stay quiet and the kernel records no trace.
This is why your detection stack has a structural blind spot here, not a tuning gap. Tools like AIDE, Tripwire, and the file-integrity monitoring built into most endpoint agents work by hashing files on disk and alerting when a hash changes. In this attack the disk file is pristine. There is nothing for them to hash that would ever look wrong. A control you may count as your privilege-escalation tripwire is, against this entire class, watching the wrong surface.
One bug class, five names, and a fix that keeps getting bypassed
DirtyClone is the fourth member of what JFrog calls the DirtyFrag family, all sharing one root cause: a kernel fast path writing into page-cache memory it does not exclusively own. A fifth bug, pedit COW (CVE-2026-46331), reaches the same outcome through a different door, the traffic-control subsystem's packet-editing action act_pedit, and Red Hat rates it important. The lineage runs back to Dirty Pipe and Dirty COW: same idea, new plumbing. The sequence began with Copy Fail (CVE-2026-31431) in April, then DirtyFrag (CVE-2026-43284 and CVE-2026-43500) on May 7, Fragnesia (CVE-2026-46300) on May 13, and DirtyClone (CVE-2026-43503) in late May, weaponized publicly on June 25. pedit COW landed its own public exploit by June 17.
Look at the May 13 entry. Fragnesia (CVE-2026-46300) exists only because it bypassed the patch that fixed DirtyFrag, slipping through a different fragment-handling helper, skb_try_coalesce(). That is the pattern worth internalizing. Every code path that moves packet fragments has to preserve that shared-memory flag, and there are many such paths. Patch one, and the next variant finds another. Chasing these one CVE at a time is a treadmill you do not win. We watched the same dynamic with a backdoor that burrowed into the Windows kernel and with a decade-long blind spot in the Linux auth stack: when a class of bug keeps resurfacing through new entry points, the durable answer is to remove the precondition, not to keep scoring the individual goals.
The real exposure map is who can reach CAP_NET_ADMIN
The CVSS 8.8 on DirtyClone reads as alarming for every Linux host, but the practical blast radius is narrower and more specific than the score suggests. Every bug in this group needs the CAP_NET_ADMIN capability to set up the network plumbing it abuses. The reason these are treated as any-local-user bugs is unprivileged user namespaces, which on Debian, Fedora, and default Ubuntu let an ordinary user grant themselves that capability inside a namespace they create. Where that feature is on, root is one logged-in account away. Where it is off, the attacker needs the capability some other way, and the risk drops sharply.
So the exposure map is not your whole fleet. It is the boxes where untrusted or semi-trusted users already have a shell and namespaces are enabled: shared hosting, continuous-integration runners, Kubernetes worker nodes, and multi-tenant jump hosts. Shared-hosting tenants have been hauled up to root before, and these bugs put them one command closer. A single-admin database server where the only login is your own is far lower risk than the raw severity implies. Cisco recently rated an SD-WAN bug medium that attackers used to take root; this is the mirror case, a high score whose real urgency depends entirely on who can log in. Triage by that, not by the number.
Disable unprivileged user namespaces, then patch in order
The fastest way to neutralize the whole family at once is to take away the precondition. On hosts that do not need unprivileged user namespaces, turn them off: set kernel.unprivileged_userns_clone=0 on Debian and Ubuntu, or cap user.max_user_namespaces at zero where that applies. Ubuntu 24.04 and newer already clamp namespace creation with AppArmor, which is why the stock exploit path fails there. This one change defangs Copy Fail, DirtyFrag, Fragnesia, DirtyClone, and pedit COW together, because none of them can reach CAP_NET_ADMIN without it.
Then patch, prioritized by exposure rather than by CVE order. DirtyClone is fixed upstream in Linux v7.1-rc5 and backported to the stable and long-term branches, so pull the current kernel from your distribution; Ubuntu, Debian, SUSE, and Red Hat have all shipped advisories. pedit COW reaches further back across distributions: Debian 11, 12, and trixie, Red Hat Enterprise Linux 8 through 10, and Ubuntu releases from 18.04 to 26.04. Patch the multi-tenant systems first. If a host cannot take the update right away, denying the vulnerable modules buys time: add esp4, esp6, and rxrpc to the module blacklist to shut the IPsec and RxRPC routes, and block act_pedit to close the traffic-control one. That sacrifices IPsec and AFS wherever you depend on them.
For detection, stop looking at file hashes and start looking at behavior, because the only visible part of this attack is the setup. Build alerts for the steps an exploit cannot skip:
-
An unprivileged process acquiring
CAP_NET_ADMIN, or creating a user namespace, on a server with no legitimate reason to do either. -
A non-root user configuring a loopback IPsec or XFRM tunnel, or the on-demand loading of
esp4,esp6, orrxrpcon a host that does not run IPsec or AFS. -
An unprivileged user adding a traffic-control
act_peditaction, which almost never happens in normal operation.
These map to MITRE ATT&CK technique T1068, exploitation for privilege escalation, and they are the signals a managed detection service should already be watching on your behalf. The on-disk binary will look fine. The path the attacker took to rewrite it will not.
| Name | CVE | Kernel path it abuses | Key date |
|---|---|---|---|
| Copy Fail | CVE-2026-31431 | algif_aead crypto path | Disclosed April 2026 |
| DirtyFrag | CVE-2026-43284, CVE-2026-43500 | IPsec and RxRPC packet paths | Disclosed May 7, 2026 |
| Fragnesia | CVE-2026-46300 | skb_try_coalesce(), bypassing DirtyFrag's fix | Disclosed May 13, 2026 |
| DirtyClone | CVE-2026-43503 | skb cloning via __pskb_copy_fclone() and skb_shift() | Working exploit published June 25, 2026 |
| pedit COW | CVE-2026-46331 | Traffic-control act_pedit action | Public exploit by June 17, 2026 |