Skip to content

Linux DirtyClone CVE-2026-43503 local privilege escalation

Summary

CVE-2026-43503, dubbed DirtyClone by JFrog Security Research, is a high-severity Linux kernel local privilege-escalation flaw in the DirtyFrag vulnerability family. JFrog published a working exploit walkthrough on June 25, 2026 showing that a local unprivileged user can gain root by manipulating shared page-cache memory through socket-buffer (skb) processing paths.

JFrog says the issue persisted after earlier DirtyFrag fixes because the same Copy-on-Write protection gap could be reached through a different packet-processing path in the XFRM/IPsec subsystem. The flaw was reported to Linux kernel maintainers in May 2026, patched in mainline, and assigned CVSS 8.8.

Tags

Why this matters

  • This is a post-compromise root path: low-privileged local shells, compromised containers, shared CI runners, research boxes, and multi-user systems become higher risk when kernels are missing the full DirtyFrag patch chain.
  • JFrog reports the exploit can be silent, leaving no kernel logs or audit traces, and can bypass common on-disk integrity checks because the primitive corrupts shared page-cache memory rather than simply modifying files through normal writes.
  • The highest-risk environments are multi-tenant Linux systems, Kubernetes/container hosts, and systems where unprivileged user namespaces let local users acquire CAP_NET_ADMIN inside a namespace.
  • DirtyClone reinforces that partial patching of a vulnerability family can leave sibling code paths exploitable; defenders should verify complete distribution backports rather than only checking the first DirtyFrag CVEs.

Public vulnerability detail

  • Name: DirtyClone.
  • CVE: CVE-2026-43503.
  • Family: DirtyFrag-style Linux kernel networking / skb page-cache Copy-on-Write flaws.
  • Impact: local privilege escalation to root.
  • Severity: CVSS 8.8, per JFrog.
  • Affected shape: kernels missing the complete DirtyFrag fix chain, including systems that patched the initial CVE-2026-43284 / CVE-2026-43500 issues but not later bypass fixes such as CVE-2026-46300 and CVE-2026-43503.
  • Reachability: local users who hold or can acquire CAP_NET_ADMIN; JFrog highlights unprivileged user namespaces as a common route.
  • Confirmed distributions in JFrog testing/context: Debian, Ubuntu, and Fedora configurations with unprivileged user namespaces enabled.
  • Patch timeline: JFrog says relevant fixes were merged in May 2026, with Linux v7.1-rc5 as the first fixed tag for this variant; production systems should follow their distribution kernel advisories and reboot into the fixed kernel.

Defender heuristics

  1. Prioritize kernel updates for container hosts, Kubernetes nodes, shared build agents, developer workstations, jump hosts, HPC/research systems, and any multi-user Linux server where untrusted users or workloads execute code.
  2. Confirm the running kernel, not just installed packages, includes the distribution backport for CVE-2026-43503 and related DirtyFrag fixes (CVE-2026-43284, CVE-2026-43500, CVE-2026-46300). Reboot after patching.
  3. If patching is delayed, evaluate temporary reduction of exposed preconditions: disable unprivileged user namespaces where business impact permits (kernel.unprivileged_userns_clone=0 on supporting distributions), restrict privileged containers, and reduce paths for untrusted workloads to gain CAP_NET_ADMIN.
  4. JFrog also points to blacklisting esp4, esp6, and rxrpc kernel modules as a workaround for the in-place decryption primitives; validate this carefully against IPsec/RxRPC business requirements before applying.
  5. Hunt for suspicious namespace and networking setup from unexpected users or workloads: unshare, clone, ip netns, tc, XFRM/IPsec configuration, unusual CAP_NET_ADMIN grants, and short-lived local-root transitions from service or CI accounts.
  6. Treat successful exploitation as possible host-root compromise even if file-integrity tools look clean; preserve volatile evidence, container runtime state, audit/process telemetry, kernel version evidence, and recent workload provenance.
  7. For Kubernetes and CI fleets, scope secrets mounted into affected nodes/runners and rotate credentials exposed to workloads that could have reached the vulnerable kernel.

2026-09-04 update: Aikido's Dirty Frag family write-up and first reported real-world activity

Aikido Security's September 4, 2026 write-up ("Dirty Frag (CVE-2026-43284): the Linux kernel bug that turns read access into root", Nicholas Thomson) covers the broader Dirty Frag family Red Hat groups under the IPsec/XFRM and RxRPC paths, and adds the first public limited real-world activity report: Microsoft has observed an attacker escalating privileges using su where the on-disk file was unchanged but the in-memory page-cache copy had been rewritten — Microsoft cautions this could be Dirty Frag or its predecessor Copy Fail, since the two are hard to distinguish from process logs alone.

The mechanism in one paragraph: splice()-style kernel paths hand the networking code a pointer into the page cache (the in-memory copy the kernel serves to any reader) without copying; the ESP (esp4/esp6) and RxRPC (rxrpc) decryption paths write in place without checking the shared/CoW marker, so an unprivileged local process can feed the contents of a read-only privileged binary (e.g. /usr/bin/su) through the buggy path and rewrite the in-memory copy — the on-disk file never changes, so integrity tooling that reads from disk sees nothing. The later Fragnesia variant (CVE-2026-46300, XFRM ESP-in-TCP) works because the original Dirty Frag fix made the kernel rely on a "this fragment is shared, copy before touching" marker that a 13-year-old (2013) fragment-merge bug silently drops — dormant until the fix started depending on it.

Exposure / triage details Aikido adds (beyond JFrog's write-up): - Three CVEs: CVE-2026-43284 (IPsec/XFRM ESP, esp4/esp6, CVSS 8.8, public path commonly via user/network-namespace creation), CVE-2026-43500 (RxRPC/AFS, rxrpc module, CVSS 7.8, no namespace needed — a narrower condition), CVE-2026-46300 "Fragnesia" (XFRM ESP-in-TCP fragment merge, CVSS 7.8, the follow-on the first fix missed). - Version confusion trap: the vulnerable pattern reaches back to ~2017 kernels; distributions backport fixes onto older kernel series, so uname -r can report a years-old version that is fully patched (e.g. a patched RHEL 8 host still says 4.18). Compare against the distribution's fixed package version, not the upstream number. - lsmod | grep -E 'esp4|esp6|rxrpc' shows which vulnerable code path is loaded — empty is not an all-clear (modules load on demand); loaded is not automatically bad (ordinary modules, safe on patched kernels). - sysctl user.max_user_namespaces: >0 means unprivileged users can create namespaces (the usual route into the ESP path); 0 closes that door for ESP only — the RxRPC path does not need namespaces. - Red Hat position: CVE-2026-43500 does not affect RHEL products; CVE-2026-43284 and CVE-2026-46300 do affect supported RHEL kernels. Ubuntu publishes exact fixed package versions per kernel line. - Containers/K8s: the affected code runs in the host kernel; a PoC for Kubernetes container-escape exists publicly and Ubuntu explicitly spells out the container-escape risk. Rebuilding images does not fix it — patch the node kernel and verify the loaded build after reboot; seccomp/pod-security/namespace restrictions reduce but do not remove reachability. - Monitoring: the realistic catch is existing audit/EDR tooling — the telltale sequence is an unknown binary dropped and run, immediately followed by su (audit exec + setuid transition events), esp4/esp6/rxrpc loading coincident with other suspicious activity on a host with no reason to run IPsec/AFS, and freshly dropped ELFs being executed. Blocking the modules does not undo page-cache changes already made; run integrity checks from a trusted environment.

Sources