This is a hidden trapdoor inside the server room, not an unlocked front door
CVE-2026-46300 is a Linux kernel sk_buff flag-propagation bug in the XFRM ESP-in-TCP path: during skb_try_coalesce(), shared page-backed fragments can be moved into a new skb without preserving SKBFL_SHARED_FRAG. Later ESP processing may then wrongly treat those fragments as safe for in-place writes, enabling page-cache corruption and local privilege escalation. Authoritative distro tracking says the published Fragnesia PoCs need the espintcp module, which first appeared upstream in Linux v5.6; older kernels such as Ubuntu 4.15/5.4 are therefore not affected in practice by the public exploit path, while affected enterprise kernels are mostly modern distro backports and custom vendor builds.
The vendor/NVD HIGH label is technically understandable because successful exploitation can end in root, but it overstates enterprise patch urgency for most fleets. This bug is not an internet-reachable initial access issue: it requires local code execution, vulnerable kernel support for the ESP-in-TCP path, and in many practical exploit chains unprivileged user namespaces or equivalent workload freedom. That makes it a post-compromise amplifier, not a front-door breach, so the real-world priority lands at MEDIUM unless you run multi-tenant Linux compute, Kubernetes nodes that execute untrusted workloads, or developer boxes with permissive namespace settings.
5 steps from start to impact.
Land local code execution
v12-security/pocs fragnesia PoC disclosed with the bug. This is the decisive friction point: the CVE does nothing for a purely remote attacker without prior access.- Local shell, container execution, or equivalent code execution on the target host
- Ability to run native binaries and relevant networking syscalls
- Requires prior compromise or tenant code execution
- Bastion-only servers and appliance-style hosts often have no untrusted local users
Reach the vulnerable ESP-in-TCP surface
esp4/esp6) and the espintcp functionality to be present and usable. Multiple vendors note that blacklisting the ESP modules blocks the attack entirely, and Ubuntu notes the public PoCs depend on espintcp, introduced upstream in v5.6.esp4oresp6available or autoloadable- Kernel/new enough distro build supporting the exploit path
- IPsec ESP modules not blacklisted
- Many fleets do not use IPsec on general-purpose servers
- Module blacklists already deployed for Dirty Frag also block this bug
esp4/esp6 are loadable. Nessus added Linux distro coverage for this CVE.Trigger skb coalescing with shared fragments
skb_try_coalesce() so shared page-backed fragments are transferred without preserving the shared-frag marker. That breaks the later safety check used by ESP processing to decide whether copy-on-write is needed before decryption.- Vulnerable kernel code path present
- Attacker can drive traffic/state to produce the coalescing condition
- This is kernel-state choreography, not a one-packet crash
- Distro backports and related fixes can invalidate public exploit assumptions
Force in-place ESP writes into page cache
- Vulnerable skb reaches ESP input with the marker stripped
- Chosen file content is resident in page cache
- Exploit reliability depends on kernel behavior and exact environment
- Some hardened hosts restrict namespaces or surrounding primitives needed by the PoC
Execute the page-cache payload as root
/usr/bin/su and then executes it to obtain elevated privileges. That is high impact, but the blast radius remains the single compromised host unless the attacker is already operating broadly across the fleet.- Writable exploit target in page cache
- Ability to execute the modified cached binary
- Requires chaining several host-local conditions first
- Produces root on a host the attacker already reached, not remote fleet-wide compromise
su, namespace creation, module load attempts, and suspicious local binaries. Disk-hash tools alone will not catch the page-cache overwrite.esp4 and esp6 where IPsec is not required — Deploy the same Dirty Frag-style module block on general-purpose Linux servers and container hosts that do not need kernel IPsec ESP. This directly removes the reachable attack surface and is the best compensating control; for a MEDIUM verdict there is no noisgate mitigation SLA, but do it during the next normal hardening/change window rather than waiting for annual patch cleanup.MEDIUM remediation path.su from already-compromised low-privilege contexts. This will not prevent the kernel bug, but it can shorten dwell time if someone is using the public PoC.- Perimeter firewalls and WAFs do nothing here because this is not an externally reachable network service bug.
- Disk-only file integrity monitoring can miss the attack because the public exploit path targets the page cache while leaving the on-disk file unchanged.
- Assuming 'no IPsec configured' equals safety is weak by itself; if the modules remain loadable, an attacker may still be able to reach the vulnerable surface unless they are blacklisted or absent.
The supporting signals.
| In-the-wild status | No confirmed in-the-wild exploitation found in the sources reviewed; CISA KEV does not list this CVE. |
|---|---|
| Public exploit / PoC | Yes. Public PoC released by William Bowling / V12 Security in v12-security/pocs (fragnesia). |
| EPSS | 0.00254 from the user-supplied intel; that is a low predicted exploitation probability signal, consistent with a local-only kernel bug. |
| KEV status | Not KEV-listed based on review of the CISA KEV catalog. |
| CVSS vector meaning | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H means local, low-complexity, low-privilege exploitation with full host impact after compromise. The weak point is the AV:L prerequisite. |
| Affected versions | Ubuntu states the public Fragnesia PoCs require espintcp, which first appeared upstream in Linux v5.6; older kernels like Ubuntu 4.15/5.4 are not affected in practice by the public exploit path. |
| Fixed versions | No single universal upstream version string is enough because enterprise kernels use backports. Ubuntu tracks fixes by commits f84eca5 and 48f6a53; Red Hat and other vendors shipped patched kernel builds in later advisories. |
| Exposure / scanning reality | Internet exposure data is largely irrelevant: Shodan/Censys/FOFA do not meaningfully measure a local kernel LPE. What matters is host population with local code execution opportunities, untrusted containers, and loadable esp4/esp6. |
| Disclosure timeline | Public disclosure and PoC release landed on 2026-05-13; the CVE record shows publication on 2026-05-23. |
| Researcher / reporting | Publicly attributed to William Bowling / V12 Security; follow-on technical discussion and mitigation guidance came from Ubuntu, Red Hat, and kernel community threads on oss-security. |
Sources.
Why this verdict
- Down from vendor
HIGH: requiresAV:L+ prior foothold. An attacker must already be on the box or in a runnable container/pod, which implies a separate compromise stage has already succeeded. - Reachability is narrower than generic kernel LPEs. Real exploitation needs the ESP/XFRM path, loadable
esp4/esp6, and for the public Fragnesia chain theespintcpfunctionality called out by Ubuntu. - Modern fleet controls cut the population further. Module blacklists, restricted unprivileged user namespaces, SELinux/AppArmor, and tight container syscall policies materially reduce the number of actually exploitable hosts.
- Still not low because impact is real and PoC is public. Successful exploitation can produce root on Linux hosts, including shared compute and some Kubernetes nodes, and defenders should not ignore a deterministic public exploit.
Why not higher?
There is no unauthenticated remote path here. Even a low-privilege attacker must already have code execution on the target and then satisfy several environment-specific prerequisites, which compounds downward pressure on severity in real fleets.
Why not lower?
This is still a kernel-level privilege escalation with a public PoC and credible host takeover impact. On multi-tenant Linux infrastructure, CI runners, and Kubernetes nodes that execute untrusted workloads, the business risk is meaningfully above routine backlog hygiene.
Crowdsourced verification payload.
Run this on the target Linux host as root or with sudo; it inspects kernel version, module availability/blacklist state, and namespace settings to determine whether the host is practically exposed to the public Fragnesia path. Save as check-cve-2026-46300.sh and run sudo bash check-cve-2026-46300.sh.
#!/usr/bin/env bash
# check-cve-2026-46300.sh
# Heuristic exposure check for CVE-2026-46300 / Fragnesia.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
ver_lt() {
[ "$1" = "$2" ] && return 1
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}
status="UNKNOWN"
reason=""
kernel_release="$(uname -r 2>/dev/null)"
kernel_base="${kernel_release%%-*}"
# Heuristic 1: public PoC path needs espintcp introduced upstream in v5.6.
if ver_lt "$kernel_base" "5.6"; then
echo "PATCHED - kernel $kernel_release is older than upstream v5.6; Ubuntu notes the public Fragnesia PoC path is not affected in practice on older kernels."
exit 0
fi
# Helper: is module blacklisted?
module_blacklisted() {
local mod="$1"
if command -v modprobe >/dev/null 2>&1; then
local out
out="$(modprobe -n -v "$mod" 2>/dev/null || true)"
echo "$out" | grep -Eq 'install /bin/(false|true)' && return 0
fi
if grep -RqsE "^[[:space:]]*install[[:space:]]+$mod[[:space:]]+/bin/(false|true)" /etc/modprobe.d /run/modprobe.d /usr/lib/modprobe.d 2>/dev/null; then
return 0
fi
return 1
}
# Helper: does module exist on disk or loaded?
module_present() {
local mod="$1"
lsmod 2>/dev/null | awk '{print $1}' | grep -qx "$mod" && return 0
find "/lib/modules/$(uname -r)" -type f \( -name "$mod.ko" -o -name "$mod.ko.xz" -o -name "$mod.ko.zst" \) >/dev/null 2>&1 && return 0
return 1
}
esp4_present=0
esp6_present=0
esp4_blocked=1
esp6_blocked=1
userns_enabled=0
module_present esp4 && esp4_present=1
module_present esp6 && esp6_present=1
module_blacklisted esp4 && esp4_blocked=0
module_blacklisted esp6 && esp6_blocked=0
# user.max_user_namespaces > 0 means user namespaces are enabled
if [ -r /proc/sys/user/max_user_namespaces ]; then
umn="$(cat /proc/sys/user/max_user_namespaces 2>/dev/null || echo 0)"
case "$umn" in
''|*[!0-9]*) userns_enabled=0 ;;
0) userns_enabled=0 ;;
*) userns_enabled=1 ;;
esac
fi
# If neither ESP module is present, practical exploitability is removed.
if [ "$esp4_present" -eq 0 ] && [ "$esp6_present" -eq 0 ]; then
echo "PATCHED - esp4/esp6 modules are not present for kernel $kernel_release."
exit 0
fi
# If both are effectively blocked, treat as patched/not exploitable for this path.
if [ "$esp4_blocked" -eq 0 ] && [ "$esp6_blocked" -eq 0 ]; then
echo "PATCHED - esp4 and esp6 are blacklisted/disabled, removing the public Fragnesia exploit path."
exit 0
fi
# If namespaces are enabled and at least one ESP module is available, likely exposed.
if [ "$userns_enabled" -eq 1 ] && { [ "$esp4_present" -eq 1 ] || [ "$esp6_present" -eq 1 ]; }; then
echo "VULNERABLE - kernel $kernel_release is new enough for the public exploit path, at least one ESP module is available, and unprivileged user namespaces are enabled. Verify vendor backport status and patch level immediately."
exit 1
fi
# Otherwise we cannot be sure: distro backports and local hardening vary.
echo "UNKNOWN - prerequisites are mixed on kernel $kernel_release. Check vendor advisory/backport status for your distro and whether esp4/esp6 can be loaded by local workloads."
exit 2