Product5 min read

DirtyFrag Mitigations on Hypernode

By Jonathan Visser on Friday, 8 May, 2026

DirtyFrag Mitigations on Hypernode

In this article

When the DirtyFrag disclosure became public, we reviewed the impact on the Hypernode platform and evaluated mitigation options for affected systems.

What is DirtyFrag?

DirtyFrag is a Linux kernel local privilege escalation vulnerability class reported on 2026-05-07 by security researcher Hyunwoo Kim (@v4bel). It is part of the same lineage as Dirty Pipe and the previously mitigated Copy Fail issue.

DirtyFrag is a chain of two separate kernel-cache write bugs:

  • CVE-2026-43284: xfrm-ESP kernel-cache write issue in the IPsec ESP decryption fast paths (esp4 and esp6)
  • CVE-2026-43500: RxRPC kernel-cache write issue in the RxRPC decryption path (rxrpc)

Together, they are reported to affect a wide range of Linux kernels shipped since approximately 2017 and to allow an unprivileged local user to obtain root privileges, without requiring a race condition and without causing kernel panics on failure.

Impact on Hypernode

Some Hypernodes were running kernel modules that may be vulnerable to DirtyFrag, though in testing, we were not successful.

As with Copy Fail, the practical risk to our customers was minimal for one key reason: DirtyFrag is not remotely exploitable. An attacker must already have local shell access to the server to use it.

DirtyFrag is not remotely exploitable. It cannot be used to gain access to a system from the outside. Instead, it becomes relevant only after an attacker already has local shell access to the server through other means. In that sense, it is not an entry point into the system, but rather something that could potentially be used after a compromise has already occurred.

We have no evidence of DirtyFrag exploitation on the Hypernode platform.

Why previous mitigations did not apply

Earlier protections put in place for Copy Fail included blacklisting algif_aead, which was designed to block a specific exploitation path within the kernel.

DirtyFrag, however, takes a different route. It reaches a similar underlying kernel area through a separate module path (xfrm-ESP). Because this path is different, the existing blacklist-based mitigation does not intercept or prevent it.

As a result, the earlier Copy Fail mitigation does not cover DirtyFrag, and a separate mitigation was required to address this distinct behaviour.

What we changed

To reduce exposure while upstream kernel patches continue to roll out, we deployed several kernel-level mitigations across affected Hypernodes.

These changes included:

  • blocking the esp4, esp6, and rxrpc kernel modules from being loaded
  • unloading those modules on systems where they were already active
  • clearing the kernel cache on affected nodes to remove any pre-existing state

The blocking was implemented via a modprobe install rule.

The mitigations were applied automatically across the platform and did not require manual intervention or restarts from customers.

As with most kernel-level mitigation work, the goal was to reduce exposure in a controlled way while avoiding unnecessary operational disruption.

Patch availability and next steps

At the time of deployment, upstream fixes for the xfrm-ESP portion of DirtyFrag are present in mainline kernels. The RxRPC variant has a reserved CVE, though broader distribution patches are still in progress across kernel and Linux distribution trees.

These mitigations align with guidance from the security researchers behind the disclosure, including Red Hat’s RHSB-2026-003 bulletin.

We will continue tracking upstream kernel releases, and distribution backports and will roll out fully patched kernels as they become available.

Closing thoughts

Vulnerabilities like DirtyFrag highlight the importance of layered mitigation and rapid response while upstream fixes are still progressing.

In this case, the focus was on understanding the realistic exposure quickly, deploying mitigations with minimal disruption, and reducing any privilege-escalation path as early as possible.

If you want more updates on everything we’re working on at Hypernode, check out our changelog

Hi! My name is Dion, Account Manager at Hypernode

Want to know more about Hypernode's Managed E-commerce Hosting? Schedule your online meeting.

schedule one-on-one meeting +31 (0) 648362102

Visit Hypernode at