DirtyFrag: Any User Account Can Become Root on Most Linux Servers. The Exploit Is Public. There Is No Patch.

Most web servers run Linux. On Linux, there is one account that can do anything without restriction: read any file on the machine, access any database, modify any configuration, install any software. It is called root, and it belongs to the system administrator. Everyone else operates within boundaries. DirtyFrag is a vulnerability that erases those boundaries. Any user with an account on a Linux server can run a single command and become root. A working exploit is public as of today. No patch exists for any major Linux distribution.

The vulnerability affects Ubuntu, RHEL, Fedora, CentOS Stream, AlmaLinux, and openSUSE Tumbleweed. One of the two underlying bugs has existed in the Linux kernel since January 2017. Researcher Hyunwoo Kim (@v4bel) reported it on April 29, 2026 with a coordinated embargo set for May 12 to give distributions time to prepare patches. On May 7, an unrelated third party broke that embargo by publishing part of the exploit publicly. Kim released the full technical write-up on May 8 rather than let a partial, potentially misleading disclosure stand uncorrected. The result: a complete, public exploit, no patches, and no CVE identifiers assigned yet.

What Root Access Means, and Why It Matters on a Shared Server

Linux is a multi-user operating system. Every process, every file, and every operation on a Linux system runs under a user account with a defined set of permissions. Most accounts are limited: a web server process can serve files but cannot read another user’s home directory. A customer’s SSH account can modify their own files but not those of other customers on the same machine.

Root is different. Root is the one account with no restrictions. A root process can read any file on the system regardless of its permissions, modify any configuration, install any software, create or delete any user account, and intercept any data in transit through the machine. It is the master key. Every system administrator has it. No one else is supposed to.

DirtyFrag is a local privilege escalation vulnerability. That phrase has a specific meaning: the attacker is already on the machine with a limited account, and the vulnerability allows them to upgrade that account to root. They do not need to guess anyone’s password. They do not need to exploit a web application. They need one thing that many people legitimately have: the ability to run code on the server.

On a shared hosting server, multiple customers’ websites run on the same physical machine under separate Linux user accounts. If one of those users runs a DirtyFrag exploit, they become root. As root, they can read every other customer’s files, every database on the server, every email stored locally, and every private key used for SSL certificates. They can install a backdoor that persists through reboots and survives future password changes. They can modify every website on the machine simultaneously. The isolation between hosting accounts, which is the entire premise of shared hosting security, does not survive a root-level compromise.

How the Vulnerability Works

The Linux kernel handles a large number of tasks that most users never think about, including processing encrypted network packets. DirtyFrag exploits a flaw in that processing path: under specific conditions, the kernel performs cryptographic operations directly on files that are already open on disk, instead of making a safe private copy first. The attacker can control what data gets written and exactly where in the file it lands.

The practical result is a precise write-anywhere primitive. Kim’s exploit uses it to overwrite the /usr/bin/su binary with minimal shellcode that sets the user and group ID to zero and launches a shell, or to modify the first line of /etc/passwd to remove the root account’s password requirement. Either path produces a root shell. Neither requires any timing luck or causes the kernel to crash on failure. Kim describes it as a deterministic logic bug: “It does not require timing luck, does not crash the kernel on failure, and succeeds on the first attempt.”

There are two separate code paths with this class of bug, and the exploit chains them to cover each other’s blind spots. The first, in the xfrm subsystem that handles IPsec encrypted traffic, has existed since a kernel commit in January 2017 and normally requires network administration capability to trigger, which an attacker can obtain by creating a user namespace on systems that allow it. The second, in the RxRPC subsystem, has existed since June 2023, requires no special capabilities at all, and is loaded by default on Ubuntu. On systems where one path is blocked, the other takes over. A single binary handles the selection automatically.

One specific detail worth noting: even systems where the Copy Fail mitigation is applied remain vulnerable. The Copy Fail flaw (CVE-2026-31431), disclosed on May 1, prompted a widely adopted mitigation of blacklisting the algif_aead kernel module. DirtyFrag uses different code paths entirely and is not blocked by that mitigation.

The Disclosure That Was Not Supposed to Happen Yet

Kim reported DirtyFrag through responsible disclosure channels on April 29, 2026, and submitted patches to the Linux kernel’s netdev mailing list. The coordinated embargo was set to expire on May 12, which would have given distributions approximately two weeks to prepare, test, and stage patched kernels. Red Hat, CloudLinux, Ubuntu, and others were in the process of doing exactly that when the embargo broke.

On May 7, an unrelated third party published the ESP variant of the exploit. At that point, the vulnerability was effectively public: anyone paying attention to security research channels had the attack code, and none of the affected distributions had patches ready. Kim published the full write-up and proof-of-concept on GitHub on May 8 to ensure the technical record was accurate and complete rather than leaving a partial, potentially misleading disclosure in place.

The result is the most difficult disclosure scenario for defenders: a public, working exploit against a vulnerability for which no official patch exists and no CVE has been assigned. The absence of a CVE number is not a technicality. CVE identifiers are how vulnerability scanners, patch management systems, and security operations tools track and prioritize known issues. Without a CVE, automated systems have nothing to match against. Security teams relying on automated scanning to identify vulnerable systems will not see DirtyFrag flagged until the CVE infrastructure catches up.

What Is Available Right Now

Patches for the Linux kernel itself have been submitted but are not yet available in any distribution’s stable or security update channels. Red Hat has published an advisory (RHSB-2026-003) covering RHEL 8, 9, and 10 and OpenShift 4, rated Important, with patches described as forthcoming. CloudLinux has published a mitigation and is actively building patched kernels, with CL7h and CL8 in the build and test phase and CL9 and CL10 following AlmaLinux’s patch preparation. KernelCare live patches are in development.

The interim mitigation available to any Linux administrator is to blacklist the vulnerable kernel modules. Adding esp4, esp6, and rxrpc to the modprobe blacklist prevents those modules from loading, removing the attack surface DirtyFrag requires. This is effective but carries a side effect: hosts running IPsec VPN tunnels via strongSwan or Libreswan will lose those tunnels. Administrators running IPsec infrastructure should evaluate that tradeoff before applying the blacklist and wait for patched kernels instead if IPsec connectivity is operationally critical.

For providers running CloudLinux with Imunify360, Imunify adds supplementary detection by blacklisting exploit-preparation scripts at the web application layer. CloudLinux is explicit that this does not replace the kernel update and is a defense-in-depth measure, not a complete mitigation.

The attack requires local code execution. Remote exploitation directly over the network is not possible. For shared hosting environments where customers have shell access, that distinction is not reassuring: shell access is the normal condition. For environments where customers have no shell access and web applications are the only execution path, the risk is lower but not zero: any web application vulnerability that enables code execution becomes a potential first step.