In the Linux kernel

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.

Why this verdict

• Down from vendor HIGH: requires AV: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 the espintcp functionality 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.

1. Blacklist 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.
2. Restrict unprivileged user namespaces — Where operationally safe, disable or tightly control unprivileged user namespaces because they are a common requirement for local/container exploitability in this family. Use this especially on shared compute, developer workstations, and Kubernetes worker nodes that run semi-trusted workloads; again, there is no noisgate mitigation SLA, but this belongs in the next hardening cycle.
3. Prioritize multi-tenant Linux first — Treat Kubernetes nodes, CI runners, shared jump hosts, and VDI/developer fleets as the hot subset because they have the highest chance of already satisfying the local-code-exec prerequisite. Single-purpose appliances and tightly controlled backend servers can follow the normal MEDIUM remediation path.
4. Watch for page-cache style post-exploitation — Tune EDR/audit rules for namespace creation, unusual module load attempts, and suspicious execution of binaries like 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.

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

Sources

1. NVD CVE-2026-46300
2. Ubuntu CVE tracker for CVE-2026-46300
3. Ubuntu mitigation blog for Fragnesia
4. oss-security disclosure thread
5. V12 Security public PoC repository
6. Red Hat Dirty Frag / Fragnesia advisory
7. CISA Known Exploited Vulnerabilities catalog
8. FIRST EPSS API reference