In June 2026, JFrog Security Research published DirtyClone (CVE-2026-43503), a Linux kernel vulnerability that lets a local user gain root on most distributions. DirtyClone is a variant of DirtyFrag that works even on systems that have already patched DirtyFrag, by laundering the kernel's shared-fragment safety flag through packet cloning.
eComscan will alert if your server is running a kernel that is vulnerable to DirtyClone. In most situations, the fix can only be applied by your server administrator / hosting provider.
Risk for ecommerce stores
DirtyClone requires local code execution to be useful, so a single-user dedicated server is at lower risk. However, the flaw is dangerous on:
- Multi-tenant hosting and shared servers
- Containers and Kubernetes clusters
- CI/CD runners and build hosts
- Any system where untrusted PHP, plugins, or extensions can run
If an attacker first lands a webshell through a vulnerable Magento extension, DirtyClone lets them escalate from the web user to full root, disable any host-level security tooling, and hide their tracks. At that point the intrusion is hard to detect.
Status
The fix has been merged into the upstream Linux kernel (mainline commit 48f6a5356a33, first released in v7.1-rc5) and distributions have begun shipping patched kernel packages. For example, Ubuntu, which tracks the issue as "Fragnesia", fixes it in 24.04 (noble) at kernel 6.8.0-124 and in 22.04 (jammy) at 5.15.0-181.
Update to a patched kernel and reboot as soon as you can. We also recommend enabling automatic security updates. If a patched kernel is not yet available for your distribution, apply the emergency mitigation below.
Emergency mitigation
Mitigation requires administrator access, so typically your hosting provider should apply this.
Block the vulnerable modules from loading and unload them if they are currently active:
cat > /etc/modprobe.d/dirtyclone.conf <<EOF
install rxrpc /bin/false
install esp4 /bin/false
install esp6 /bin/false
EOF
rmmod rxrpc esp4 esp6 2>/dev/null || true
The rxrpc module is rarely used outside AFS deployments, so disabling it has no impact on regular ecommerce workloads. The esp4 and esp6 modules implement IPsec ESP. Only blacklist these if your server does not use IPsec VPNs, otherwise IPsec tunnels will fail to come up.
DirtyClone also needs unprivileged user namespaces to reach the vulnerable code without root. On Debian and Ubuntu you can disable them as defense-in-depth, provided your workloads do not require them:
sysctl -w kernel.unprivileged_userns_clone=0
echo 'kernel.unprivileged_userns_clone=0' > /etc/sysctl.d/99-dirtyclone.conf
For container hosts running untrusted workloads, also restrict capabilities and namespace creation through seccomp and AppArmor profiles.
Frequently asked questions
Why does eComscan add a temporary iptables rule and send UDP traffic to 10.99.0.2?
To tell a vulnerable kernel from a patched one, eComscan runs a small, defused probe that reproduces the DirtyClone packet-clone path and checks whether the kernel mishandles it. On the versions where the probe shells out, this briefly installs a rule such as:
iptables -t mangle -A OUTPUT -p udp --dport 4500 -j TEE --gateway 10.99.0.2
The entire probe runs inside a private, throwaway user and network namespace that eComscan creates and then discards. The rule and the 10.99.0.2 address exist only inside that isolated namespace, never in your host firewall or routing table, which is why the rule is gone the moment the probe finishes. 10.99.0.2 is a synthetic clone target configured on loopback inside the namespace, so no packet ever leaves your server and no real host network state is changed.
The probe is harmless by design. Unlike a real exploit, it directs the kernel's write at a private in-memory page that eComscan owns, then reads back a marker to decide "vulnerable" or "safe." It never targets a real file.
My EDR/XDR flagged this as T1562.001 or T1070. Is that a real compromise?
No. Security tooling may link the iptables rule with MITRE T1562.001 (Impair Defenses) or T1070 (Indicator Removal), but this is a false positive against a sandboxed probe. eComscan does not modify your host firewall, disable defenses, or remove logs. The probe state lives and dies inside an isolated namespace. You can safely add an exception for eComscan's probe. If you key that exception on the iptables process, note that newer versions run the check via netlink and will no longer spawn iptables.
More information
In this article
Protect your store now!
Block all known Magento attacks, while you schedule the latest critical patch until a convenient moment. No more downtime and instability from rushed patching.
Get Sansec Shield
