Dirty Frag (CVE-2026-43284 and CVE-2026-43500): What These New Linux Kernel Vulnerabilities Mean and How to Respond

On May 7, 2026, security researcher Hyunwoo Kim publicly disclosed a family of Linux kernel vulnerabilities collectively named Dirty Frag. The disclosure landed on the oss-security mailing list after the responsible disclosure embargo was broken by an unrelated third party publishing a working exploit. The result is that every major Linux distribution shipped today, including Ubuntu, Red Hat Enterprise Linux, CentOS Stream, AlmaLinux, Rocky Linux, Fedora, Debian, openSUSE, and CloudLinux, contains code that lets any local user gain root in a single command. A working public proof-of-concept exists. CISA has not yet listed it in the Known Exploited Vulnerabilities catalog as of this writing, but given the public exploit and the universal coverage, that listing is likely imminent.

If you are a Gotekky managed server customer, your server has been mitigated. The rest of this guide explains what Dirty Frag is, why it is structurally a different problem from Copy Fail (CVE-2026-31431) even though it produces the same outcome, what we did on managed servers, and what you should do if you operate self-managed Linux servers, particularly cPanel and Webuzo nodes on AlmaLinux or CloudLinux.

What Dirty Frag actually is

Dirty Frag is not one bug. It is a chain of two related Linux kernel bugs in the network stack that share the same exploitation pattern: an unprivileged user can write attacker-controlled bytes into the kernel's page cache, then use that primitive to overwrite a small region of an in-memory copy of a privileged binary like su or sudo, then trigger that binary to gain root. It is the same exploitation strategy as Copy Fail, but the entry points are completely different code paths.

The two bugs are tracked under separate CVE identifiers:

• CVE-2026-43284 is the IPsec ESP half. It lives in the in-place decryption code of the esp4 and esp6 modules (the Encapsulating Security Payload for IPv4 and IPv6), and was introduced by a kernel commit in January 2017. Coincidentally, the same January 2017 commit was also the root cause of CVE-2022-27666, a separate buffer overflow vulnerability disclosed years ago.
• CVE-2026-43500 is the rxrpc half. It lives in the rxrpc kernel module (Andrew File System remote procedure calls) and was introduced by a kernel commit in June 2023.

The two bugs are separate but the researcher published them together because they cover each other's gaps. The IPsec ESP variant requires the attacker to be able to create unprivileged user namespaces. Ubuntu blocks unprivileged user namespace creation by default through an AppArmor policy, so the ESP variant fails on stock Ubuntu. The rxrpc variant does not need namespaces, so it works on Ubuntu, but the rxrpc kernel module is not loaded by default on most distributions, so it fails on stock RHEL and AlmaLinux. The combination guarantees universal coverage: whichever variant fails on your distribution, the other one succeeds.

Why this is structurally different from Copy Fail

Copy Fail (CVE-2026-31431) lives in the algif_aead module of the kernel's userspace crypto API. The mitigation everyone deployed last week is a modprobe blacklist of that single module, which has essentially no operational impact because no production hosting workload uses algif_aead.

Dirty Frag lives in IPsec ESP and rxrpc. The mitigation is more disruptive in two specific ways. First, blacklisting esp4 and esp6 breaks IPsec VPNs. If any of your customers run IPsec VPN connections to or from the server, those connections will stop working. Second, blacklisting rxrpc breaks Andrew File System mounts, which essentially nobody uses, but verify it before applying. AWS guidance for Amazon Linux extends the recommended blacklist to also include ipcomp4 and ipcomp6 (IP payload compression for IPv4 and IPv6), which share the same vulnerable code class.

The most important practical difference: the algif_aead mitigation that protected against Copy Fail does not protect against Dirty Frag. They are separate code paths. A server that has only the Copy Fail mitigation applied is still vulnerable to Dirty Frag and will fall to the public exploit. Both mitigations are needed simultaneously until kernel patches are installed across the fleet.

Distribution patch status as of May 8, 2026

The patch landscape is moving quickly because multiple distributions started rebuilding kernels the moment the disclosure landed. The current state:

• AlmaLinux: patched kernels are in production repositories as of May 8, 15:22 UTC. AlmaLinux 8 is affected only by CVE-2026-43284 because rxrpc does not ship. AlmaLinux 9 and 10 are affected by CVE-2026-43500 only if kernel-modules-partner from the Devel repository is installed. AlmaLinux 7 is end of life and will not receive a patch.
• CloudLinux: KernelCare livepatches and patched kernels in active build and test as of May 7. KernelCare delivers fixes without a reboot, which is the cleanest path for CL7, CL8, and CL9 nodes.
• Red Hat Enterprise Linux: classified Dirty Frag as Important severity, expediting patches across supported RHEL releases. Status is rolling out across the supported tree.
• Ubuntu, Debian, Fedora, openSUSE: distribution security teams have acknowledged the issue and patches are in progress. Each distribution's security advisory feed will publish them as they ship.
• Amazon Linux: working to confirm the full range of affected versions. Amazon's bulletin recommends the module blacklist (extended to include ipcomp4/ipcomp6) plus disabling unprivileged user namespaces as interim measures.

What Gotekky has done about it on managed servers

For our cPanel and Webuzo fleet running on AlmaLinux and CloudLinux, we are deploying mitigations within hours of this guide being published. The deployment is structured by distribution because the right path differs:

• CloudLinux nodes with KernelCare: receive the livepatch automatically through kcarectl. No reboot required, no module blacklist needed once the patch is applied. KernelCare verifies the CVEs as patched in its kcarectl --patch-info output.
• AlmaLinux 8, 9, 10 nodes: kernel update via dnf upgrade, then reboot during the next maintenance window. AlmaLinux published patched kernel-6.12.0-124.55.3.el10_1 on May 8 with the equivalent for 8.x and 9.x.
• Any node where a same-day reboot is not feasible: interim modprobe blacklist of esp4, esp6, ipcomp4, ipcomp6, and rxrpc, plus the existing algif_aead blacklist for Copy Fail. The interim mitigation does not require a reboot and is removed once the patched kernel is installed.
• AlmaLinux 7 nodes: AlmaLinux 7 is end of life and will not receive a patch. We are applying the module blacklist plus the user.max_user_namespaces=0 sysctl as a defense in depth measure on these nodes, and we are accelerating migration off AlmaLinux 7 onto AlmaLinux 9 as a separate project.

For customers on Gotekky managed plans, no action is required. We have communicated the mitigation timing through our usual support channels and we will update this guide as the patched kernel rollout completes across the fleet.

If you operate self-managed AlmaLinux or CloudLinux servers, do this today

The mitigation path depends on which distribution you run and whether you have KernelCare. Pick the row that matches your fleet.

CloudLinux 7, 8, 9 with KernelCare

This is the cleanest path. From the CloudLinux blog, KernelCare livepatches for both CVEs are in active build and test. Run:

kcarectl --update
kcarectl --patch-info | grep -E "CVE-2026-43284|CVE-2026-43500"

If both CVEs appear as patched, you are done. No module blacklist needed, no reboot required. KernelCare delivers the fix in place once CloudLinux ships it. If you do not have KernelCare on those nodes, follow the AlmaLinux path below.

AlmaLinux 8, 9, 10

Patched kernels are in the production repositories as of May 8, 15:22 UTC. Update and reboot:

sudo dnf clean metadata
sudo dnf upgrade kernel
sudo reboot

After reboot, verify with uname -r. The patched kernel version on AL10 is kernel-6.12.0-124.55.3.el10_1 with equivalents on 8.x and 9.x. Check the AlmaLinux blog for the exact target version for your stream. AlmaLinux 9 and 10 are affected by CVE-2026-43500 only if you have kernel-modules-partner from the Devel repository installed. Verify with rpm -qa | grep kernel-modules-partner. If you do, ensure it is updated alongside the kernel.

AlmaLinux 7

End of life. No patch coming. Apply the module blacklist below as a stopgap and migrate off AlmaLinux 7 as a priority project. CloudLinux 7 with KernelCare is a viable interim if migration takes longer than a few weeks.

Interim module blacklist for any node you cannot reboot today

This works on every supported distribution. As root:

cat > /etc/modprobe.d/dirtyfrag.conf <<'EOF'
install esp4 /bin/false
install esp6 /bin/false
install ipcomp4 /bin/false
install ipcomp6 /bin/false
install rxrpc /bin/false

# Drop the page cache
sync
echo 3 > /proc/sys/vm/drop_caches
EOF

# Check if any of these are currently loaded
lsmod | grep -E "esp4|esp6|ipcomp4|ipcomp6|rxrpc"

# Unload them if so
rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

# Verify they cannot be loaded
modprobe esp4 && echo "STILL LOADABLE" || echo "BLOCKED"

Output of the final check should be BLOCKED. Important: this blacklist breaks IPsec VPN connections (esp4 and esp6 carry IPsec encrypted payloads). If any customer or service on the server uses IPsec VPN, plan accordingly. The blacklist also breaks Andrew File System mounts (rxrpc), which is rarely an issue on hosting workloads. The ipcomp4 and ipcomp6 entries are AWS's recommended addition to address the same code class proactively.

Optional defense in depth: disable unprivileged user namespaces

This blocks the IPsec ESP variant entirely (CVE-2026-43284) but leaves the rxrpc variant exploitable on systems where rxrpc is loaded. Useful as a hardening layer on top of the module blacklist:

echo "user.max_user_namespaces=0" > /etc/sysctl.d/dirtyfrag.conf
sysctl --system

This breaks rootless containers (Podman rootless, sandboxed browsers, Flatpak). On a dedicated cPanel or Webuzo host none of those should be in use, so the practical impact is none. On AlmaLinux 7 nodes that are not getting a kernel patch, applying this is recommended.

Verifying you are protected

After applying mitigations, two checks confirm the state of the system:

cat > /root/check-dirtyfrag-protection.sh <<'EOF'
#!/usr/bin/env bash

RED="\033[31m"
GREEN="\033[32m"
BLUE="\033[34m"
BOLD="\033[1m"
RESET="\033[0m"

PASS_COUNT=0
WARN_COUNT=0

pass() {
  echo -e "${GREEN}PASS${RESET}: $1"
  PASS_COUNT=$((PASS_COUNT + 1))
}

warn() {
  echo -e "${RED}WARNING${RESET}: $1"
  WARN_COUNT=$((WARN_COUNT + 1))
}

info() {
  echo -e "${BLUE}$1${RESET}"
}

check_module() {
  local mod="$1"

  echo
  info "Checking kernel module: $mod"

  if modprobe -n -v "$mod" 2>/dev/null | grep -qE '^install /bin/false|^install /bin/true'; then
    pass "$mod is blocked by a modprobe install rule."
  elif modprobe "$mod" >/dev/null 2>&1; then
    warn "$mod appears to be loadable. Review the mitigation."
  else
    pass "$mod could not be loaded."
  fi
}

clear
echo -e "${BOLD}Dirty Frag protection check${RESET}"
echo "================================"

check_module esp4
check_module rxrpc

echo
info "Checking unprivileged user namespaces"

NS_VALUE="$(sysctl -n user.max_user_namespaces 2>/dev/null || echo unknown)"

if [ "$NS_VALUE" = "0" ]; then
  pass "user.max_user_namespaces is set to 0."
else
  warn "user.max_user_namespaces is set to $NS_VALUE, not 0."
fi

echo
echo -e "${BOLD}Summary${RESET}"
echo "-------"

if [ "$WARN_COUNT" -eq 0 ]; then
  echo -e "${GREEN}Protected: all checks passed.${RESET}"
else
  echo -e "${RED}Review needed: $WARN_COUNT warning(s) found.${RESET}"
fi

echo
echo "Passed checks: $PASS_COUNT"
echo "Warnings: $WARN_COUNT"

echo
echo -e "${BOLD}Technical details for administrators${RESET}"
modprobe -c | egrep '^(install|blacklist) (esp4|rxrpc)' || echo "No esp4/rxrpc modprobe rules found."
EOF

chmod +x /root/check-dirtyfrag-protection.sh
/root/check-dirtyfrag-protection.sh

If the server has been rebooted onto a patched kernel, the module blacklist is no longer required (though leaving it in place is harmless). Verify the running kernel version against your distribution's published patched build number. For AlmaLinux 10 that is kernel-6.12.0-124.55.3.el10_1 or later.

Specific guidance for cPanel and Webuzo servers

cPanel and Webuzo servers are structurally exposed to Dirty Frag the same way they were exposed to Copy Fail: any cPanel or Webuzo user with shell access, or any successful PHP exploit against any hosted website, becomes a candidate for taking over the entire server. The combination with CVE-2026-41940 (the cPanel authentication bypass disclosed April 28) is particularly dangerous because the cPanel bug grants WHM root remotely with no credentials, and Dirty Frag turns that into Linux host root within seconds. A server that has been patched against CVE-2026-41940 but not against Dirty Frag is not safe.

The recommended order for cPanel and Webuzo operators:

1. Apply the cPanel and WHM patch for CVE-2026-41940 if not already done. Run /scripts/upcp --force as root and verify the build number matches the patched version published in the cPanel advisory.
2. Apply the Dirty Frag mitigation appropriate to your distribution: KernelCare livepatch on CloudLinux with subscription, dnf upgrade kernel + reboot on AlmaLinux 8/9/10, module blacklist on AlmaLinux 7 or any node where reboot is not feasible today.
3. Verify the existing Copy Fail mitigation (algif_aead blacklist) is still in place. Both mitigations are needed simultaneously until kernel patches are installed.
4. Audit cPanel and Webuzo user accounts and shell-enabled accounts for unfamiliar entries. The CVE-2026-41940 exposure window ran from late February to April 28, so any unfamiliar accounts created in that window should be treated as suspicious.

The bigger pattern this represents

Dirty Frag is the second universal Linux kernel privilege escalation in nine days. Copy Fail and Dirty Frag are not the same bug, but they are the same bug class: deterministic, no race condition required, no kernel panic on failure, very high success rate, exploitation in a single command. The researcher Hyunwoo Kim has now published two of these in rapid succession, found through a combination of automated code scanning and targeted human analysis. There will be more.

The structural lesson for hosting infrastructure has not changed since last week, but it has been reinforced: shared-kernel multi-tenancy is the underlying risk, and patching cadence alone is not a sufficient defense when bug discovery is now this fast. Defense in depth across kernel hardening, prompt patching, monitoring, isolation between customer accounts, restricted shell access, and per-account resource and namespace limits is now the operational baseline. We are continuing to invest in monitoring and isolation work on managed infrastructure as a result of this run of disclosures, and we will publish more on that work as it comes online.

References for self-managed operators

The primary sources for this guide and for ongoing tracking are AlmaLinux's blog post on Dirty Frag, the CloudLinux blog post covering KernelCare and patched kernels, Red Hat's RHSB-2026-003 customer portal advisory, the AWS security bulletin extending the affected module list to include ipcomp4 and ipcomp6, the oss-security mailing list disclosure thread from May 7 by Hyunwoo Kim, and the public proof-of-concept on GitHub. Each of these is updated in place as patches roll out, so check them rather than relying on this guide for the latest patched kernel version numbers.