Fragnesia (CVE-2026-46300): The Third Linux Kernel Root Exploit in Three Weeks and What to Do About It

On May 13, 2026, security researcher William Bowling and the V12 Security team publicly disclosed Fragnesia (CVE-2026-46300), a new Linux kernel local privilege escalation vulnerability. A working public proof-of-concept exists and any unprivileged local user can use it to gain root in a single command. It is the third kernel root exploit requiring a patch in three weeks, following Copy Fail (CVE-2026-31431) on April 29 and Dirty Frag (CVE-2026-43284 and CVE-2026-43500) on May 7.

If you are a Gotekky managed server customer, your server is already protected. The mitigation we deployed for Dirty Frag last week blocks Fragnesia as well. No additional action is required on managed servers. The rest of this guide explains what Fragnesia is, why the Dirty Frag mitigation covers it, what is different from the previous two vulnerabilities, and what self-managed CloudLinux and AlmaLinux operators should do today.

What Fragnesia is and how it differs from Dirty Frag

Fragnesia is in the same broad kernel area as Dirty Frag (the XFRM and ESP subsystems of the Linux network stack) but it is a separate, distinct bug. The Dirty Frag patches do not address it. The name comes from the underlying logic flaw: during TCP receive coalescing, the socket buffer forgets that a fragment is shared, which lets an attacker abuse the ESP-in-TCP path to perform arbitrary byte writes into the kernel page cache of any readable file.

Technically, when a TCP socket transitions into espintcp ULP mode after data has been spliced from a file into the receive queue (via splice or sendfile), the kernel treats those queued file pages as ESP ciphertext and decrypts them in place. The AES-GCM keystream gets XORed into cached file pages, and by controlling the IV nonce, an unprivileged process turns this into a one-byte arbitrary write into the page cache per trigger invocation. The public proof-of-concept writes a 192-byte position-independent ELF stub into the page-cache copy of /usr/bin/su. The next su invocation executes the modified code and grants the attacker root.

The pattern is the same as Copy Fail and Dirty Frag: write to the page cache, not to disk. File integrity monitoring sees nothing. Reboots clear the modification because memory is reset, but by then the attacker has already established persistence through some other means. No race condition is required. The exploit is deterministic in a single command.

Why the Dirty Frag mitigation protects you

The Fragnesia attack path requires the esp4 or esp6 kernel modules to be loaded. The Dirty Frag mitigation we recommended last week blacklists exactly those modules along with rxrpc, ipcomp4, and ipcomp6. A server that has applied that mitigation cannot load the modules Fragnesia needs to execute. The protection is incidental but complete.

This means Gotekky managed servers and any self-managed server where the Dirty Frag mitigation was applied last week are already protected against Fragnesia. Verify with:

cat > /root/check-fragnesia-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}Fragnesia protection check${RESET}"
echo "==========================="

check_module esp4
check_module esp6
check_module ipcomp4
check_module ipcomp6
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|esp6|ipcomp4|ipcomp6|rxrpc)' || echo "No Fragnesia-related modprobe rules found."
EOF

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

If all checks pass with zero warnings, no further action is needed on Fragnesia until patched kernels are released. If any module appears loadable, the Dirty Frag mitigation was never applied or has been reverted, and the server is vulnerable to both Dirty Frag and Fragnesia simultaneously.

What this means for the affected CloudLinux versions specifically

CloudLinux confirmed that Fragnesia affects CloudLinux 7h, 8, 9, and 10. CloudLinux 7 (the original, not 7h) is not affected because it ships an older kernel that predates the vulnerable code path. CloudLinux is preparing patched kernels and KernelCare livepatches for all affected versions. The KernelCare livepatch will be the cleanest path for production servers: it applies the fix to the running kernel with no reboot required.

AlmaLinux 8, 9, and 10 are also affected because they share the same upstream kernel code. AlmaLinux's patched kernels for Fragnesia are in testing as of this writing and will move to production repositories once verified. The update path on AlmaLinux is the standard dnf upgrade kernel followed by a reboot, identical to the Dirty Frag patch flow.

What Gotekky did on managed servers

The Dirty Frag mitigation we deployed last week (blacklisting esp4, esp6, rxrpc, ipcomp4, and ipcomp6 across all managed servers and applying the unprivileged user namespace sysctl on AlmaLinux 7 nodes) already blocks the Fragnesia exploitation path. We verified module status on every managed server within hours of the Fragnesia disclosure and confirmed all are protected.

For CloudLinux managed servers with KernelCare subscriptions, we will apply the Fragnesia livepatch as soon as it is published, removing the need for a reboot. For AlmaLinux nodes, we will apply the patched kernel during the next scheduled maintenance window, identical to the Dirty Frag rollout. The interim module blacklist remains in place during the entire process. Customers do not need to take action.

If you operate self-managed servers, do this today

The decision tree is the same as Dirty Frag with one addition: verify the mitigation is in place, then drop the page cache to revert any prior in-memory tampering that may have occurred before the mitigation was applied.

If you already applied the Dirty Frag module blacklist

You are protected against Fragnesia. Verify with the modprobe commands above. After confirming the modules are blocked, drop the page cache to ensure no in-memory tampering from a prior exploitation attempt remains. As root:

sync
echo 3 > /proc/sys/vm/drop_caches

This forces the kernel to release cached file pages and reload them from disk on next access. Any modifications an attacker may have written to in-memory copies of binaries are erased. This is a low-impact operation but it will cause a brief I/O spike as frequently-accessed files reload.

If you have not applied the Dirty Frag module blacklist

Apply it now. The mitigation is the same single configuration file:

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
EOF

# Unload any currently loaded modules
rmmod esp4 esp6 ipcomp4 ipcomp6 rxrpc 2>/dev/null

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

This blocks both Dirty Frag and Fragnesia simultaneously. As noted in the Dirty Frag guide, the blacklist breaks IPsec VPN connections (esp4, esp6) and Andrew File System mounts (rxrpc). Verify no customer or service depends on these on your servers before applying.

CloudLinux with KernelCare

If you run CloudLinux 7h, 8, 9, or 10 with KernelCare, the livepatch for Fragnesia will deliver automatically once CloudLinux publishes it. Check status with:

kcarectl --update
kcarectl --patch-info | grep CVE-2026-46300

If the CVE appears as patched, you are done. No reboot, no module blacklist needed. If your CloudLinux servers do not have KernelCare and a reboot is not feasible immediately, apply the module blacklist as the interim and schedule the kernel upgrade for the next maintenance window.

AlmaLinux 8, 9, 10

Once AlmaLinux moves the Fragnesia patched kernel from testing to production (likely within 24 to 48 hours of disclosure), update and reboot:

sudo dnf clean metadata
sudo dnf upgrade kernel
sudo reboot

Until then, the module blacklist is your protection.

Imunify360 customers have additional coverage

If you run Imunify360 on your servers, it already blocks the Fragnesia exploit through its real-time exploitation detection. CloudLinux confirms that Imunify360 uses extended heuristics to identify and mitigate new indicators related to this vulnerability class. This is an additional defense layer rather than a replacement for the kernel update or the module blacklist, but it provides coverage during the window before a patched kernel is applied. Customers running Imunify360 are protected against currently observed exploitation attempts in the meantime.

The pattern this represents and what it means for hosting infrastructure

Three Linux kernel privilege escalation vulnerabilities in three weeks is not a coincidence. Copy Fail, Dirty Frag, and Fragnesia are different bugs, found by different researchers, in different kernel subsystems, but they share the same exploitation pattern: write to the page cache to modify privileged binaries in memory, then trigger those binaries for instant root. The discovery cadence reflects two trends. First, AI-assisted code review tooling is now genuinely effective at finding deterministic primitives like this one. Second, the page-cache-to-root pattern is a class of vulnerability rather than a single bug, and once one researcher demonstrated it works, others started looking for similar primitives.

For hosting infrastructure, the operational reality is that this cadence is unlikely to slow down soon. Defense in depth across kernel hardening, prompt patching, monitoring, isolation between customer accounts, and ideally per-tenant kernels through technologies like microVMs is now the baseline. The Dirty Frag mitigation has now blocked two vulnerabilities (Dirty Frag and Fragnesia) with the same configuration file, which is the right kind of defense: broad enough to catch related future bugs without requiring custom mitigation for each new disclosure. If a fourth XFRM/ESP kernel vulnerability is disclosed next week, the same mitigation will likely cover it too. That is not a guarantee, but it is the pattern that has held across three disclosures so far.

Gotekky maintains separate guides for Copy Fail and Dirty Frag with the full technical and operational detail for each. Read those alongside this guide if you have not already, particularly if you operate self-managed servers that may have missed the earlier mitigation.