Every team running Linux workloads, which in practice means almost every DevOps team in Europe running anything on Hetzner, AWS, Azure, or bare metal, now has a new local privilege escalation bug to patch, and this one is built to hide from the tools you use to catch intrusions after the fact.
How DirtyClone works
CVE-2026-43503, named DirtyClone by JFrog Security Research, is a local privilege escalation vulnerability with a CVSS score of 8.8. It belongs to the same family as Dirty COW and Dirty Pipe, kernel bugs that have periodically resurfaced for a decade because they exploit the same class of memory-handling assumption: that a page of memory marked as shared or file-backed cannot be silently treated as writable packet data.
The technical root cause is in __pskb_copy_fclone(), the kernel function responsible for cloning socket buffer fragments. When packets are cloned, this function drops the SKBFL_SHARED_FRAG safety marker, a flag that was itself introduced specifically to close an earlier related bug (DirtyFrag). With the marker dropped, file-backed or externally owned memory pages get treated as ordinary packet data, and an in-place network write operation lands where it should only ever have been allowed to copy.
The practical result: an unprivileged local user can manipulate the Linux page cache to write into root-owned, supposedly read-only files, escalating to root or escaping a container.
Why it is worse than a typical LPE
Most privilege escalation exploits leave some artefact behind: a modified binary, an unusual process tree, an entry in an audit log. DirtyClone does not. The attack manipulates memory that the kernel already considers legitimately writable, so there is no on-disk integrity violation for file monitoring tools to catch, and no kernel log entry marking the escalation. For any organisation relying on file integrity monitoring or audit trails as a detection control, rather than prevention, this vulnerability is functionally invisible after the fact.
Who is affected
The attack has been confirmed to work on Debian, Ubuntu, and Fedora wherever unprivileged user namespaces are enabled, which is the default configuration on most cloud images and container hosts. That includes the large majority of Linux instances running on Hetzner Cloud, DigitalOcean droplets, and equivalent VPS and dedicated hosting used by European small and mid-size engineering teams.
Fixes and mitigations
The fix merged into mainline Linux on May 21 as commit 48f6a5356a33, shipped in kernel v7.1-rc5, and has since been backported to Ubuntu 22.04 and 24.04, Debian bullseye, bookworm, and trixie, and RHEL 9 and 10. If you cannot patch immediately, two mitigations reduce exposure: setting kernel.unprivileged_userns_clone=0 to block the namespace privilege the exploit relies on, and blacklisting the esp4, esp6, and rxrpc kernel modules to remove the in-place decryption code paths the proof-of-concept uses.
Given that a working exploit is already public, treat this as an immediate patch cycle for any fleet of Linux hosts, not a routine maintenance item.
If you need help auditing kernel versions across a fleet of cloud or dedicated servers, building a patch cadence that does not depend on waiting for a CVE number to appear in your ticketing system, or hardening container hosts against local privilege escalation, contact Excello Digital. We help European engineering teams keep infrastructure patched without slowing down delivery.