high

CVE

CVE-2026-46300

CWE

CWE-123

Affected Surface

Linux kernel XFRM ESP-in-TCP / espintcp ULP, Linux kernel sk_buff shared-fragment coalescing paths, Systems with esp4, esp6, or espintcp support available before vendor fixes, CloudLinux 7h, 8, 9, and 10 according to CloudLinux advisory status, Ubuntu linux kernel packages pending evaluation for CVE-2026-46300, Multi-tenant Linux hosts, self-hosted CI runners, developer workstations, and container nodes that allow untrusted local code plus user/network namespace setup

Fragnesia is a Linux kernel local privilege escalation disclosed on 13 May 2026 and assigned CVE-2026-46300. It sits in the same broad page-cache corruption family as Copy Fail and Dirty Frag, but it is not just a rename of either issue. Public disclosures describe it as a separate bug in the XFRM ESP-in-TCP path with a public proof of concept already available.

The practical impact is straightforward: an unprivileged local attacker can corrupt the in-memory page cache for a read-only system binary and then execute that modified cached copy as root. The file on disk remains unchanged, so a simple file-integrity check may miss the attack until the host reboots or drops the affected cache.

Affected packages and projects

The affected project is the Linux kernel, specifically the networking and IPsec/XFRM implementation around ESP-in-TCP:

  • Linux kernel XFRM ESP-in-TCP, also referenced as the espintcp ULP.
  • Shared-fragment handling during sk_buff coalescing in kernel networking paths.
  • Systems where esp4, esp6, or ESP-in-TCP support can be loaded or used before vendor fixes are installed.
  • CloudLinux 7h, 8, 9, and 10 according to CloudLinux’s advisory. CloudLinux 7 is listed as not affected.
  • Ubuntu kernel packages are marked high priority and pending evaluation across multiple kernel package lines in Ubuntu’s CVE tracker.

Exposure depends on kernel build options, loaded modules, distribution backports, and runtime policy. AWS says Amazon Linux does not provide the espintcp module and is not affected, while still planning a networking hardening patch for defense in depth.

For application-security teams, the highest-risk environments are multi-tenant Linux systems where untrusted code can run locally: self-hosted CI runners, build farms, developer workstations, shared Kubernetes nodes, and container hosts that allow user and network namespaces plus the relevant XFRM setup path.

Exploit shape

The public analysis describes a deterministic page-cache write primitive:

  1. A local process splices file-backed pages into a TCP receive queue.
  2. The socket transitions into ESP-in-TCP mode.
  3. The kernel treats the queued file pages as ESP ciphertext and decrypts them in place.
  4. By controlling AES-GCM nonce material, the attacker steers one-byte writes into the cached file page.
  5. Repeating the trigger lets the exploit patch a small payload into the page-cache copy of a privileged binary.

Wiz, CloudLinux, and the oss-security disclosure all describe a public proof of concept that overwrites the first bytes of /usr/bin/su in memory with a small ELF payload that calls setresuid(0,0,0) and executes /bin/sh. Because the modification is cache-resident, not a persistent write to disk, the root shell can appear without the on-disk binary changing.

That makes Fragnesia particularly relevant after any application compromise. A web shell, malicious package install, escaped build step, or compromised developer tool that starts as an ordinary user can become a host-level root incident if the kernel is exposed.

Relationship to Dirty Frag

Fragnesia shares the same operational neighborhood as the earlier Dirty Frag chain covered in our Dirty Frag research: XFRM, ESP, page-cache corruption, and local root escalation. The difference is the vulnerable path. Dirty Frag used ESP/IPsec and RxRPC issues tracked as CVE-2026-43284 and CVE-2026-43500; Fragnesia is CVE-2026-46300 and centers on ESP-in-TCP.

The overlap still matters because the temporary mitigation is nearly the same. If a host already blocked esp4, esp6, and rxrpc after Dirty Frag, public vendor guidance says that mitigation also blocks the Fragnesia path until patched kernels are available.

Remediation

Apply vendor kernel updates as soon as they are available for the distribution and kernel line you run. Do not assume that one vendor’s exposure or fixed status applies to another. AWS, Ubuntu, CloudLinux, Fedora, and other Linux vendors are tracking status differently based on kernel configuration and module availability.

Until fixed kernels are deployed, disable the vulnerable ESP-related modules where IPsec is not required:

printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' | sudo tee /etc/modprobe.d/fragnesia.conf
sudo rmmod esp4 esp6 rxrpc 2>/dev/null || true

Regenerate initramfs if your distribution needs it for module blacklist changes to apply at boot. Test before broad rollout: disabling esp4 or esp6 can break hosts that terminate or transit IPsec tunnels, including strongSwan and Libreswan deployments.

Also restrict the local primitives that make exploitation practical:

  • Disable or restrict unprivileged user namespaces where feasible.
  • Avoid granting containers CAP_NET_ADMIN unless there is a reviewed requirement.
  • Use seccomp, AppArmor, SELinux, or equivalent policy to limit namespace creation, XFRM netlink operations, and unusual use of splice() from untrusted workloads.
  • Treat self-hosted CI jobs and developer tool installs as untrusted code execution zones, not just package-management events.

Detection and response

Disk-only integrity checks are not enough because the exploit modifies page cache rather than the underlying file. Prefer runtime and syscall telemetry:

  • Unexpected creation of user and network namespaces by application workers, build jobs, or developer tools.
  • XFRM netlink activity from processes that do not manage IPsec.
  • Attempts to load or use esp4, esp6, or ESP-in-TCP on hosts that do not normally run IPsec.
  • Suspicious splice(), sendfile(), or pipe-backed file movement immediately before privilege transitions.
  • Executions of /usr/bin/su or other setuid binaries that are followed by unusual root shells or process trees.

If exploitation is suspected, patch or mitigate first, then reboot the system or drop page cache so in-memory binary modifications are removed. CloudLinux recommends dropping caches after applying mitigation because the public proof of concept can leave /usr/bin/su modified in memory:

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

Treat any successful exploitation as a full host compromise. Rotate credentials reachable from affected workloads, review recent CI and package-install activity, and inspect other nodes that ran the same untrusted code before the kernel fix was applied.

Tracking status

The OSV API did not return an entry for CVE-2026-46300 during this research run, so teams should currently rely on CVE/NVD tracking, distribution advisories, kernel mailing-list patches, and cloud-provider bulletins for patch status. Re-check OSV and vendor feeds as advisories converge.

References