DirtyClone (CVE-2026-43503): CloudLinux Is Already Protected

DirtyClone (CVE-2026-43503) is a Linux kernel local-privilege-escalation in the networking stack, disclosed with a public proof-of-concept from JFrog Security Research. It is not a new class of bug. It is the third named exploit of the same shared-fragment-marker weakness we already wrote about as Dirty Frag (May 7) and Fragnesia (May 13), and it is closed by the exact same fix we shipped in May. If your kernel is current, or you run KernelCare, there is nothing new to do here.

DirtyClone lands amid a run of Linux kernel privilege-escalation disclosures, and we know that cadence is wearing on server operators. This post exists so that operators searching for “DirtyClone” can confirm and know quickly where they stand.

What DirtyClone is

Every one of these bugs turns on a single kernel bookkeeping marker. The kernel tags any network buffer (skb) that holds page references it does not own with a “shared fragment” marker, and the code that decides whether a payload can be safely modified in place keys off that marker. When a helper that moves paged fragments between buffers forgets to carry the marker across, the destination buffer ends up holding references to pages it doesn’t own — including page-cache pages backing root-owned, read-only files — while reporting that it’s safe to write over.

The dangerous sink is ESP (IPsec) input decryption, which performs in-place AES-CBC decryption. Point that in-place write at the mislabeled buffer and you can decrypt directly over the page cache of a privileged file — a DirtyCow-style overwrite. In the public PoC, an unprivileged user sets up an ESP security association and overwrites /usr/bin/su, yielding a uid=0 root shell.

DirtyClone reaches that same ESP sink by a slightly different route than its siblings: it runs inside an unprivileged user + network namespace, installs a netfilter TEE rule that clones ESP-in-UDP packets through a copy helper that drops the marker, then installs ESP transport rules so the mislabeled clone is decrypted in place over the target file’s page cache. Different path in, but an identical outcome. Red Hat rates it Important, CVSS 7.0 (Red Hat; NVD scores it 8.8), and lists RHEL 9 and RHEL 10 as affected — RHEL 6, 7, and 8 are not affected.

Why this is an N-day, not a fresh zero-day

The public exploit reproduces only on older, un-updated kernels. The same kernels that predate the Dirty Frag / Fragnesia errata. On a current stock kernel that already carries that fix, the PoC does not reproduce. And any host running the KernelCare livepatch is protected regardless of kernel version. In other words, the errata that closed Fragnesia in May already closed DirtyClone. A machine is only exposed if it has been sitting un-patched since before then and is not on KernelCare.

That is why we’re treating this as a known, already-fixed issue resurfacing under a new name.

Details: Public PoC (JFrog Security Research) · Red Hat CVE-2026-43503 · Red Hat Bugzilla 2480902 · Sibling CVE-2026-46300 (Fragnesia)

Affected CloudLinux versions

DirtyClone’s affected surface is narrower than Fragnesia’s.

Making sure you’re protected

The action, if any, is simply to be current.

On a stock kernel (CL9 / CL10): update to at least CL9 kernel-5.14.0-611.54.5.el9_7 or CL10 kernel-6.12.0-124.56.3.el10_1 (or newer), then reboot if the running kernel changed.

# CL9 / CL10
sudo dnf update

On KernelCare: the livepatch that closes this is already on the main feed. It arrives automatically on the next scheduled run, or on demand:

kcarectl --update

Optional mitigation for hosts you can’t update yet

If an affected host (CL9 / CL10) can’t be updated or livepatched immediately, breaking either link in the exploit chain neutralizes it. Both are optional stopgaps, not a substitute for the fix.

If you already applied the Fragnesia or Dirty Frag mitigation, you are already covered. The ESP module blacklist is byte-identical:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 2>/dev/null; true"

Alternatively, disabling unprivileged user namespaces removes the primitive the PoC uses to set up its rules:

sudo sysctl -w user.max_user_namespaces=0
echo 'user.max_user_namespaces = 0' | sudo tee /etc/sysctl.d/99-dirtyclone.conf

Compatibility. Do not apply the ESP blacklist on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels — it disables the kernel-side ESP transforms. Disabling unprivileged user namespaces breaks rootless Podman/Docker, unshare(1), and browser sandboxes; it’s fine on most server fleets but disruptive on container or developer hosts. Revert any mitigation by removing the dropfile under /etc/modprobe.d/ or /etc/sysctl.d/ and reloading (sudo sysctl –system).

If a host may have been targeted before you mitigated, the exploit modifies SUID binaries in the page cache before gaining root. Force a reload from disk:

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

How to verify you are patched

On KernelCare, note that the livepatch metadata records this fix under its sibling CVE, CVE-2026-46300, not CVE-2026-43503 (the 43503 identifier has not yet propagated to the patch metadata). Grep for 46300:

kcarectl --info | grep kpatch-build-time
kcarectl --patch-info | grep -iE 'CVE-2026-46300|CVE-2026-43503'

On a patched host, –patch-info prints a line like [CVE-2026-46300] …. Do not verify with kcarectl –info | grep CVE-… — –info does not list CVE identifiers and returns empty even on a fully patched system; use –patch-info. A build time on or after May 14, 2026 includes the fix.

On a stock kernel, compare uname -r against your distribution’s current kernel. Anything from the mid-May errata onward carries it.

References

• Public PoC — DirtyClone (JFrog Security Research)
• Red Hat CVE-2026-43503
• Red Hat Bugzilla 2480902 — propagate shared-frag marker through frag-transfer helpers
• Sibling CVE-2026-46300 (Fragnesia) — same root bug, shared fix
• Prior advisories in this family: Fragnesia · Dirty Frag