✕
Two new kernel LPEs, same class as CopyFail

DirtyFrag and Copy Fail 2: Electric Boogaloo are Linux kernel privilege escalation exploits targeting the esp4 and esp6 IPsec modules. Any unprivileged local user becomes root. If you hardened against CVE-2026-31431, you still need to act. This is a different attack surface.

The short version: Two new LPEs have dropped that abuse the Linux kernel’s esp4.ko and esp6.ko modules (the kernel’s IPsec ESP implementation). Like CopyFail, they give an unprivileged user a straight path to root. The mitigation is fast and safe for most Magento hosts.

What Are These Exploits?

DirtyFrag is a memory fragmentation flaw in the kernel’s IPsec packet processing path. A local attacker can use it to corrupt kernel memory via esp4/esp6 and escalate to root. Same end result as CopyFail, different subsystem.

Copy Fail 2: Electric Boogaloo hits a similar logic flaw to CVE-2026-31431 but through the ESP protocol handlers rather than AF_ALG.

Both exploits share the same attack surface (esp4 / esp6 modules) and the same mitigation. Blocking both modules, plus rxrpc which has a related exposure, takes care of both.

Why This Matters for Magento

Same story as CopyFail. Magento is a high-value target:

  • Initial access arrives via web RCE (CosmicSting, PolyShell, SessionReaper), compromised extensions, or weak admin credentials
  • Shell access is gained as the unprivileged web user (www-data, nginx, etc.)
  • DirtyFrag / Copy Fail 2 turns that into root

On shared hosting: root access means all tenants are compromised.

On cloud/Kubernetes: container escape via root gives access to the entire node and shared page cache.

On CI runners: any untrusted code running on a self-hosted runner (e.g. GitHub Actions, GitLab Runner) becomes root immediately.

Emergency Fix (5 Minutes)

Block esp4, esp6, and rxrpc kernel modules. No reboot or kernel update required.

sudo tee /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install rxrpc /bin/false
EOF
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

Verify:

lsmod | grep -E 'esp4|esp6|rxrpc'  # Should return nothing
cat /etc/modprobe.d/dirtyfrag.conf  # Should show all three install lines

Deploy Across Infrastructure

- hosts: magento_servers
  become: true
  tasks:
    - name: Write dirtyfrag modprobe block
      copy:
        dest: /etc/modprobe.d/dirtyfrag.conf
        content: |
          install esp4 /bin/false
          install esp6 /bin/false
          install rxrpc /bin/false
        owner: root
        group: root
        mode: '0644'

    - name: Unload esp4 if loaded
      command: rmmod esp4
      failed_when: false
      changed_when: true

    - name: Unload esp6 if loaded
      command: rmmod esp6
      failed_when: false
      changed_when: true

    - name: Unload rxrpc if loaded
      command: rmmod rxrpc
      failed_when: false
      changed_when: true

Run it once:

ansible-playbook deploy-dirtyfrag-disable.yaml -i hosts.yaml

Will This Break Anything?

For a standard Magento web server, almost certainly not.

esp4 and esp6 are the kernel’s ESP (Encapsulating Security Payload) implementation, the encryption component of IPsec. rxrpc is the kernel’s RxRPC transport, used primarily by AFS (Andrew File System). None of these are needed for:

  • HTTP/HTTPS web serving
  • MySQL / MariaDB / PostgreSQL connections
  • Redis, Varnish, Elasticsearch / OpenSearch
  • OpenVPN (TLS-based, does not use kernel IPsec)
  • WireGuard (has its own kernel module, does not use esp4/esp6)
  • SSH

Where you might see an impact:

ScenarioImpact
Kernel-level site-to-site IPsec VPN (strongSwan, Libreswan)VPN will drop. Switch to WireGuard or OpenVPN, or keep esp4/esp6 on VPN gateways only
AWS VPC with customer-managed VPN attachments using kernel IPsecVerify first. AWS-managed VPNs typically handle this outside the instance
Azure / GCP overlay networking via IPsecRare on standard VM instances. Cloud SDN usually operates below this layer
Corporate network requiring IPsec transport mode to reach DBConnection to DB will break. Requires an IPsec-aware workaround
AFS (Andrew File System) mounts via rxrpcAFS mounts will fail. Not a Magento concern

If you’re unsure, check whether any active network tunnels use kernel IPsec before blocking:

ip xfrm state   # Active IPsec security associations (should be empty on a plain web server)
ip xfrm policy  # Active IPsec policies

Empty output means you’re not using kernel IPsec and can safely block the modules.

Long-Term Fix (This Week)

Patch your kernels. Patched releases are available across all major distributions, same cadence as CopyFail. Once patched, leave the modprobe blocks in place as defence-in-depth.

  • Ubuntu / Debian: apt update && apt upgrade
  • RHEL / CentOS / Fedora: dnf update kernel
  • Amazon Linux 2: yum update kernel
  • SUSE: zypper update kernel-default
  • Arch: pacman -Syu
uname -r  # Check current kernel after reboot

Personal Sitrep

Another week, another kernel LPE.

Having infrastructure-as-code pays off here. Same Ansible pattern as CopyFail, new modprobe conf file. The emergency fix across ~60 nodes was done in under 15 minutes, in waves, with zero service disruption.

If you’re still patching CopyFail and now this lands on your desk: the mitigations are independent (/etc/modprobe.d/disable-algif.conf for CopyFail, /etc/modprobe.d/dirtyfrag.conf for this). Apply both.

For More Details

See the docs page for Ansible playbooks, validation steps, and IPsec impact assessment.

Previous entry in this series: CopyFail (CVE-2026-31431)

Credits

Initial heads up on DirtyFrag from Sansec. Follow-up on Copy Fail 2 from Jeroen Boersma.

References