Fragnesia (CVE-2026-46300) — Mitigation and Kernel Update on CloudLinux

Less than a week after Dirty Frag, researcher William Bowling and the V12 team disclosed a third Linux kernel local privilege escalation in the same broad area (XFRM / ESP) and named it Fragnesia. A working public proof-of-concept exists. Any unprivileged local user can use it to gain root in a single command.

Warning

Fragnesia is a separate bug from Dirty Frag, not a re-announcement. It is, however, in the same XFRM/ESP class and the immediate mitigation is identical. Customers who have already applied the Dirty Frag mitigation need no further action until patched kernels are released.

Don't want a third reboot in three weeks?

Fragnesia is the third Linux kernel privilege escalation requiring a patch and reboot on affected hosts in just three weeks, following Copy Fail (April 29) and Dirty Frag (May 7). If you do not want to emergency-patch and reboot multiple times a month, KernelCare is the alternative we recommend. It automatically applies kernel security fixes to a running server, with no reboot and no maintenance window. Once the Fragnesia livepatch is published, servers using KernelCare will receive it automatically. See Stream 3 below for current status.

The flaw is a logic bug in the kernel's ESP-in-TCP path (the espintcp ULP). When a TCP socket transitions into espintcp ULP mode after data has already been spliced from a file into the receive queue (via splice(2) / sendfile(2)), the kernel treats those queued file pages as ESP ciphertext and decrypts them in place. The AES-GCM keystream is 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 of any readable file per trigger invocation — yielding a deterministic write primitive that the public PoC turns into root in a single command. No race condition is required.

The published PoC targets /usr/bin/su directly: a 192-byte position-independent ELF stub is written into the page-cache copy of the binary, and the next su invocation runs it as root.

Details: public PoC and write-up · upstream fix discussion · NVD entry — CVE-2026-46300

Status as of May 13, 15:00 UTC

Patched kernels and KernelCare livepatches for affected CloudLinux versions are in active build/test. See Update instructions below for current per-stream status. This article will be updated in place as each stream reaches release.

Subscribe to the CloudLinux status page for updates.

Affected CloudLinux versions

Version	Affected	Will be patched via
CloudLinux 7 (CL7)	No	—
CloudLinux 7h (CL7h)	Yes	CloudLinux kernel
CloudLinux 8 (CL8)	Yes	CloudLinux kernel
CloudLinux 9 (CL9)	Yes	AlmaLinux kernel
CloudLinux 10 (CL10)	Yes	AlmaLinux kernel

A KernelCare livepatch that automatically deploys the patched version without requiring a reboot will also be available as an alternative on all affected versions. See Stream 3 below for current status.

Apply this mitigation now

Until a patched kernel or KernelCare livepatch is installed, blacklist the esp4, esp6, and rxrpc modules so they cannot be loaded, and unload them if already present:

sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

If you already applied this exact mitigation for Dirty Frag, no further action is required. The file already exists and Fragnesia is blocked by the same rule.

To revert after a patched kernel is installed:

sudo rm /etc/modprobe.d/dirtyfrag.conf

Compatibility: esp4 / esp6 are the kernel-side ESP transforms used by IPsec. Disabling them breaks IPsec tunnels that rely on the kernel data path on the affected machine. Do not apply this mitigation on hosts that terminate or transit IPsec / strongSwan / Libreswan tunnels. rxrpc is the AF_RXRPC transport used almost exclusively by AFS clients and is not present on typical web-hosting servers.

Restore page-cache binaries after mitigation

The exploit can modify legitimate system binaries (the public PoC overwrites /usr/bin/su) in the page cache as part of gaining root, so applying the mitigation alone is not enough on systems that may have been targeted before the mitigation was in place. After mitigating, drop the page cache to force a reload from disk:

sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"

Additional protection for Imunify360 users

Imunify360 already blocks the exploit related to Fragnesia (CVE-2026-46300) and uses extended heuristics to identify and mitigate new indicators more quickly.

This is an additional layer of defense. It does not replace the kernel update, but customers running Imunify360 are covered against currently observed exploitation attempts in the meantime.

Update instructions

Update: May 15, 12:30 UTC

For customers running the LTS kernel, patched versions are released. Target versions:

kernel-lts-5.14.0-284.1101.el8.tuxcare.7.els33 or newer
kernel-lts-5.14.0-284.1101.el9.tuxcare.7.els33 or newer

Update with:

dnf update 'kernel-lts*' --enablerepo=cloudlinux-updates-testing
reboot

There are three release streams. Use the one that applies to your CloudLinux version. As patches land, this article will be updated in place — check the timestamps on the callouts in each stream below.

Stream 1 — CloudLinux kernel (CL7h, CL8)

Update: May 15, 12:20 UTC

Final patched kernels for CL7h and CL8 are released. Target versions:

CL7h: kernel-4.18.0-553.124.3.lve.el7h or newer
CL8: kernel-4.18.0-553.124.3.lve.el8 or newer

Both are available in the beta channel and rolling out to stable. Because the stable rollout is gradual, use the following command if you want to install immediately.

On CL8:

yum update cloudlinux-release --enablerepo=cloudlinux-updates-testing yum update --enablerepo=cloudlinux-rollout-7-bypass 'kernel*' rebootOn CL7h:

yum update cloudlinux-release --enablerepo=cloudlinux-updates-testing
yum update 'kernel*' --enablerepo=cloudlinux-rollout-7-bypass --releasever=7h

reboot

Update: May 15, 9:30 UTC

The AlmaLinux 8 fix that CloudLinux kernels for CL7h and CL8 build on has been rebuilt as kernel-4.18.0-553.124.3.el8_10 (now in AlmaLinux testing) to incorporate additional upstream patches. CloudLinux kernel builds are being updated accordingly. CL target package versions and channel availability will be added here on release.

Update: May 14, 16:00 UTC

An additional exploit path for this vulnerability has been identified. We are preparing kernel versions that include the additional fixes. Target package versions and channel availability will be added here on release. Until then, the mitigation above remains the primary defense.

Status: May 13, 15:00 UTC

Patched kernels are in build/test on top of the AlmaLinux fix. Target package versions and channel availability will be added here when released.

Both will be CloudLinux rebuilds of the upstream fix.

Updating from the CloudLinux beta channel

Once the patched kernel lands in the beta channel, enable it for a single update:

Instructions for updating CL8 from the beta channel — cloudlinux-updates-testing:

yum --enablerepo=cloudlinux-updates-testing update 'kernel*'
reboot
uname -r

Instructions for updating CL7h from the beta channel — cl7h_beta:

yum --enablerepo=cl7h_beta update 'kernel*'
reboot
uname -r

Updating from the CloudLinux stable channel

Once the kernel reaches the stable channel, a plain update will pull the patched version, no extra repo enablement needed:

yum update 'kernel*'
reboot
uname -r

Stream 2 — AlmaLinux kernel (CL9, CL10)

Update: May 15, 9:30 UTC

The patched kernels in the AlmaLinux testing repository have been rebuilt to incorporate additional upstream patches. Updated target versions:

CL9 / AlmaLinux 9: kernel-5.14.0-611.54.5.el9_7 or newer
CL10 / AlmaLinux 10: kernel-6.12.0-124.56.3.el10_1 or newer

These supersede the prior test builds (5.14.0-611.54.4.el9_7 and 6.12.0-124.56.2.el10_1). If you installed the earlier test kernel, update and reboot again.

Promotion to production repositories will follow once community verification completes.

Update: May 14, 16:00 UTC

An additional exploit path for this vulnerability has been identified. AlmaLinux is preparing new kernel versions with the additional fixes. Updated target versions will be added here on release. Until then, the mitigation above remains the primary defense.

Update: May 13, 18:30 UTC

Patched kernels are available in the AlmaLinux testing repository. Target versions:

CL9 / AlmaLinux 9: kernel-5.14.0-611.54.4.el9_7 or newer
CL10 / AlmaLinux 10: kernel-6.12.0-124.56.2.el10_1 or newer

Promotion to production repositories is pending. See the AlmaLinux advisory for upstream details.

Status: May 13, 15:00 UTC

AlmaLinux is preparing the patched kernel. Target package versions and repository availability will be added here as soon as upstream announces.

CloudLinux 9 and CloudLinux 10 use the AlmaLinux kernel directly. The patched kernel is expected to appear first in the AlmaLinux testing repository, with promotion to production repositories shortly after.

Installing from the AlmaLinux testing repository

The almalinux-release-testing package is not in CloudLinux repositories. Install it from a direct URL, update the kernel, then disable the testing repo.

For CL10:

# 1. Enable the AlmaLinux 10 testing repo
dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-1.el10.x86_64.rpm

# 2. Update the kernel
dnf update 'kernel*'

# 3. Reboot
reboot

# 4. Verify
uname -r

# 5. Disable the testing repo
dnf config-manager --disable almalinux-testing

For CL9 — same flow, replace the URL in step 1:

dnf install -y https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-1.el9.noarch.rpm

Once the kernel reaches AlmaLinux production repositories

A plain update will pull the patched version, no testing-repo step needed:

dnf update 'kernel*'
reboot
uname -r

Stream 3 — KernelCare livepatch (all affected versions)

Update: May 18, 13:00 UTC

The KernelCare livepatch rollout is now complete on the main feed across all primary distributions: AlmaLinux ELS/FIPS variants, the EL8 family, Debian 11, Debian 12, and Ubuntu Jammy. KernelCare-subscribed servers receive the fix automatically on the next kcarectl --update.

Update: May 15, 14:00 UTC

Livepatches incorporating the additional upstream fix are now promoted to the main feed. KernelCare-subscribed servers on the main feed receive the fix automatically on the next kcarectl --update.

Patch IDs released today:

K20260515_34 — Rocky Linux 10
K20260515_27 — Oracle Linux 9
K20260515_21 — Oracle Linux 8 (UEK 7)
K20260515_20 — Oracle Linux 9 (UEK 7)
K20260515_01 — Ubuntu Noble
K20260515_02 — Ubuntu Noble (AWS)

Update: May 15, 13:00 UTC

A new wave of KernelCare livepatches incorporating the additional upstream fix has been released to the testing feed. Affected distributions in this wave: EL8, EL9, Debian 12, and AlmaLinux 10.

To deploy from the testing feed:

kcarectl --update --prefix test

Update: May 14, 7:00 UTC

First KernelCare livepatches are released for CloudLinux 9 customers running ELS or FIPS variants of the AlmaLinux 9 kernel.

KernelCare-subscribed servers in scope receive the fix on the next kcarectl --update. Confirm with kcarectl --patch-info | grep CVE-2026-46300.

Update: May 13, 16:30 UTC

Livepatch candidate validated against the public proof-of-concept. Patches will be released to the testing feed first before promoting to the main feed.

Status: May 13, 15:00 UTC

KernelCare engineering is preparing livepatches. Per-distro release status will be appended here as patches roll out.

The KernelCare livepatch for this vulnerability is being prepared. KernelCare ships it to the testing feed first and promotes to the main feed after validation. To deploy from the testing feed once available:

kcarectl --update --prefix test

Once promoted to the main feed, KernelCare-subscribed systems receive the fix automatically through the standard livepatch flow:

kcarectl --update

Not using KernelCare yet? You can roll out the patches for your entire fleet automatically, and without needing reboots. Get started in just a few minutes. Find more information here.

How to verify you are patched

After update + reboot:

uname -r

Compare to the target version for your CloudLinux stream above.

For KernelCare:

kcarectl --info | grep kpatch-build-time

Build time 2026-05-14 or later includes the Fragnesia fix. Alternatively, once patch metadata is finalized:

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

References