This is a loaded trapdoor inside the server room, not a cannon pointed at the internet
CVE-2026-43284 is a Linux kernel local privilege-escalation bug in the XFRM/IPsec ESP receive path. When MSG_SPLICE_PAGES feeds shared pipe-backed pages into a UDP skb, the ESP input path can wrongly take an in-place decrypt fast path and write into memory the skb does not privately own, creating a page-cache write primitive that can be steered into root. Upstream tracking shows the vulnerable lineage begins with commit cac2661c53f3 in 2017 and remains affected until the stable backports referenced by the CVE record; distro fixes are backported well below mainline, for example Debian fixed it in 5.10.251-4, 6.1.170-3, 6.12.86-1, and 7.0.4-1.
The vendor's HIGH 8.8 overstates enterprise urgency a bit because the decisive friction is attacker position: this is local, low-privilege, post-initial-access exploitation. That said, it stays in HIGH because the exploit path is public, reliable, race-free, and turns a minor foothold on Linux into full root across broadly deployed kernels—especially ugly on CI runners, multi-user bastions, container nodes, VDI, and other shared-compute estates.
4 steps from start to impact.
Land a low-privilege local foothold
dirtyfrag only matters after that foothold exists.- Local code execution on the Linux host or inside a container sharing the host kernel
- Privileges no higher than a normal user account
- No unauthenticated remote path in the CVSS vector
- MFA, PAM hardening, workload isolation, and admission controls may stop the attacker before this CVE matters
Confirm the vulnerable ESP path exists
esp4/esp6 or equivalent built-in kernel support. Public guidance from Red Hat and Ubuntu both treat disabling or unloading these modules as a valid mitigation because without the path, the exploit chain for this CVE loses its sink. A public PoC exists via dirtyfrag (V4bel).esp4oresp6available as a loaded or loadable kernel module, or compiled in- Kernel build in an affected range
- Many enterprise Linux systems do not actively use IPsec ESP
- Some fleets already blacklist unused networking modules
Trigger shared-frag in-place decrypt
MSG_SPLICE_PAGES, feeds them into UDP, and drives the ESP input path so the kernel decrypts in place over shared fragments. The important point is not packet sniffing or VPN access from outside; it is the local ability to coerce a buggy skb ownership assumption. The bug is attractive because the exploitation path was described publicly as deterministic rather than race-bound.- Ability to run the required local syscall sequence
- Reachability of the vulnerable XFRM/ESP receive path
- Kernel feature coverage varies by distro and kernel config
- Least-privilege container profiles or seccomp rules can reduce syscall freedom in some platforms
Turn page-cache corruption into root
- Writable primitive reaches a useful page-cache-backed target
- Attacker can execute the corrupted privileged program
- Single-host blast radius unless the attacker already has lateral movement
- Some immutable or minimal images reduce useful setuid targets
The supporting signals.
| In-the-wild status | I found public exploit code and public n-day weaponization, but no authoritative evidence of active exploitation campaigns and no CISA KEV listing during this assessment. |
|---|---|
| PoC availability | Yes — researcher Hyunwoo Kim's dirtyfrag PoC is publicly referenced at github.com/V4bel/dirtyfrag; oss-security also documents separate n-day weaponization from the public fix commit. |
| EPSS | 0.38453 from the prompt; percentile was not verified from a primary EPSS feed in this assessment. |
| KEV status | Not listed in CISA KEV. No CISA KEV entry for CVE-2026-43284 was found during this assessment. |
| CVSS vector, interpreted | CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H means local attacker, low privileges, no user click, full root-class impact. That is serious, but it is still a post-compromise privilege escalation, not an external edge exploit. |
| Affected range | Ubuntu tracks it as introduced by commit cac2661 and fixed by f4c50a4; the CVE record shows affected kernels from cac2661c53f35cbe651bef9b07026a5a05ab8ce0 before stable fix fe785bb3a8096dffcc4048a85cd0c83337eeecad. |
| Fixed versions / backports | Mainline reference appears in Debian notes as 7.1-rc3 for commit f4c50a4. Debian backports fixed the issue in 5.10.251-4, 6.1.170-3, 6.12.86-1, and 7.0.4-1; enterprise vendors also shipped lower-version backports, so do not rely on upstream version comparison alone. |
| Scanning / exposure data | This is not internet-census friendly. Because the attack vector is local, Shodan/Censys/GreyNoise-style counts are not the right exposure lens; the real exposure metric is how many Linux hosts run vulnerable kernels with esp4/esp6 present and allow untrusted local code. That is an inference from the CVSS vector and vendor mitigations, not a public host-count source. |
| Disclosure timeline | Public researcher disclosure appeared on 2026-05-07 on oss-security; the CVE record was published on 2026-05-08; NVD shows the record last modified on 2026-05-26. |
| Researcher / reporting org | Public disclosure credits Hyunwoo Kim (@v4bel). Kernel.org is the CNA for the CVE record. |
noisgate verdict.
The single biggest downward pressure is that this bug requires an existing local foothold with low privileges; that makes it a post-compromise escalation issue, not a perimeter-breaker. It remains HIGH because once that foothold exists, public exploit paths turn it into reliable root on widely deployed Linux kernels with very little execution friction.
Why this verdict
- Downgrade for attacker position: vendor 8.8 assumes severe impact, but the chain starts at
AV:L/PR:L; an attacker must already have local execution or a container/workload foothold. - Hold at HIGH for exploit maturity: public PoC and public n-day weaponization exist, and the path is described as reliable rather than a brittle race.
- Hold at HIGH for fleet blast radius: vulnerable kernels have been around since 2017 and the bug hits common Linux estates; shared-compute nodes, CI runners, bastions, and container hosts amplify practical risk once one workload lands.
Why not higher?
This is not an unauthenticated edge-service bug and it does not create initial access by itself. The requirement for a pre-existing low-privilege local position compounds downward pressure because many enterprise prevention layers should stop the attacker before this CVE becomes relevant.
Why not lower?
Public exploit availability and deterministic root keep this out of MEDIUM territory. If you run any environment where untrusted local code is normal—developers, researchers, CI, batch jobs, shells, containers, or multi-tenant workloads—the friction drops sharply and the business impact becomes immediate host compromise.
What to do — in priority order.
- Block unused ESP modules — If the host does not need IPsec ESP, blacklist and unload
esp4andesp6. This directly removes the vulnerable path and is the most surgical temporary control; for a HIGH verdict, deploy within 30 days. - Tighten local code execution — Prioritize hosts where ordinary users, CI jobs, notebooks, or containers can run arbitrary code. Reduce shell access, shrink sudo-able populations, and gate interactive debug/exec paths; this matters because the CVE is only useful after a local foothold. Deploy within 30 days.
- Harden shared-compute nodes first — Patching priority should be highest on Kubernetes nodes, CI runners, AI/GPU boxes, VDI, bastions, university/research clusters, and any Linux system with many low-privilege principals. These environments erase the biggest friction point—attacker position—so they deserve the first wave. Deploy within 30 days.
- Monitor privileged exec anomalies — Instrument alerts for unexpected execution of setuid binaries,
su,sudo, and other root-transition points from non-admin users or build agents. Detection is imperfect here, but it is one of the few practical runtime tripwires for successful exploitation. Deploy within 30 days.
- A WAF or external perimeter block does not help; the attack vector is local, not inbound HTTP.
- Internet vulnerability scanning does not meaningfully measure exposure here; you need host/kernel/module inventory.
- File-integrity monitoring alone is weak because exploitation can target the page cache rather than persist obvious on-disk file changes.
Crowdsourced verification payload.
Run this on the target Linux host as root or with enough privileges to read /proc/config.gz, /boot/config-*, and module metadata. Invoke it exactly as sudo bash ./check-cve-2026-43284.sh; it performs a best-effort host assessment and prints PATCHED, VULNERABLE, or UNKNOWN based on module exposure plus limited distro/version logic.
#!/usr/bin/env bash
# check-cve-2026-43284.sh
# Best-effort exposure check for CVE-2026-43284 (Dirty Frag xfrm/ESP path)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=ERROR
set -u
CVE="CVE-2026-43284"
KREL="$(uname -r 2>/dev/null)"
OS_ID=""
OS_VERSION_ID=""
STATUS="UNKNOWN"
REASON="insufficient version mapping"
log() { printf '%s\n' "$*"; }
have_cmd() { command -v "$1" >/dev/null 2>&1; }
load_os_release() {
if [[ -r /etc/os-release ]]; then
# shellcheck disable=SC1091
. /etc/os-release
OS_ID="${ID:-}"
OS_VERSION_ID="${VERSION_ID:-}"
fi
}
module_available() {
local m="$1"
if grep -qE "^${m} " /proc/modules 2>/dev/null; then
return 0
fi
if have_cmd modinfo && modinfo "$m" >/dev/null 2>&1; then
return 0
fi
return 1
}
module_blacklisted() {
local m="$1"
grep -RhsE "^[[:space:]]*install[[:space:]]+${m}[[:space:]]+/bin/false|^[[:space:]]*blacklist[[:space:]]+${m}([[:space:]]|$)" \
/etc/modprobe.d /run/modprobe.d /usr/lib/modprobe.d /lib/modprobe.d 2>/dev/null | grep -q .
}
config_enabled() {
local sym="$1"
if [[ -r /proc/config.gz ]] && have_cmd zgrep; then
zgrep -qE "^${sym}=(y|m)$" /proc/config.gz 2>/dev/null && return 0
fi
if [[ -r "/boot/config-${KREL}" ]]; then
grep -qE "^${sym}=(y|m)$" "/boot/config-${KREL}" 2>/dev/null && return 0
fi
return 1
}
ver_lt() {
# dpkg --compare-versions style if available, otherwise sort -V fallback
local a="$1" b="$2"
if have_cmd dpkg; then
dpkg --compare-versions "$a" lt "$b"
return $?
fi
[[ "$(printf '%s\n%s\n' "$a" "$b" | sort -V | head -n1)" == "$a" && "$a" != "$b" ]]
}
print_summary() {
log "${STATUS}"
log "reason=${REASON}"
log "kernel=${KREL}"
[[ -n "$OS_ID" ]] && log "os=${OS_ID} ${OS_VERSION_ID}"
exit "$1"
}
load_os_release
ESP4_AVAIL=0
ESP6_AVAIL=0
ESP4_BL=1
ESP6_BL=1
CFG4=1
CFG6=1
module_available esp4 && ESP4_AVAIL=1
module_available esp6 && ESP6_AVAIL=1
module_blacklisted esp4 && ESP4_BL=0 || ESP4_BL=1
module_blacklisted esp6 && ESP6_BL=0 || ESP6_BL=1
config_enabled CONFIG_INET_ESP && CFG4=0 || CFG4=1
config_enabled CONFIG_INET6_ESP && CFG6=0 || CFG6=1
# If neither module is available and neither feature is compiled in, host is effectively not exposed.
if [[ $ESP4_AVAIL -eq 0 && $ESP6_AVAIL -eq 0 && $CFG4 -ne 0 && $CFG6 -ne 0 ]]; then
STATUS="PATCHED"
REASON="esp4/esp6 not present and kernel config does not expose ESP support"
print_summary 0
fi
# If everything is blacklisted and not loaded, treat as effectively mitigated.
if [[ $ESP4_AVAIL -eq 1 || $ESP6_AVAIL -eq 1 || $CFG4 -eq 0 || $CFG6 -eq 0 ]]; then
if [[ $ESP4_BL -eq 0 && $ESP6_BL -eq 0 ]] && ! grep -qE '^(esp4|esp6) ' /proc/modules 2>/dev/null; then
STATUS="PATCHED"
REASON="esp4/esp6 blacklisted and not loaded; host effectively mitigated"
print_summary 0
fi
fi
# Best-effort Debian family mapping from Debian tracker fixed versions.
# This checks installed package metadata where available; vendor backports on other distros are not covered.
if [[ "$OS_ID" =~ ^(debian|ubuntu)$ ]] && have_cmd dpkg-query; then
PKGVER=""
if dpkg-query -W -f='${Version}\n' linux-image-"$KREL" >/dev/null 2>&1; then
PKGVER="$(dpkg-query -W -f='${Version}\n' linux-image-"$KREL" 2>/dev/null | head -n1)"
elif dpkg-query -W -f='${Version}\n' linux-image-generic >/dev/null 2>&1; then
PKGVER="$(dpkg-query -W -f='${Version}\n' linux-image-generic 2>/dev/null | head -n1)"
fi
if [[ -n "$PKGVER" ]]; then
case "$OS_VERSION_ID" in
11*) FIX="5.10.251-4" ;;
12*) FIX="6.1.170-3" ;;
13*) FIX="6.12.86-1" ;;
*) FIX="" ;;
esac
if [[ -n "$FIX" ]]; then
if ver_lt "$PKGVER" "$FIX"; then
STATUS="VULNERABLE"
REASON="Debian-family package version ${PKGVER} is older than known fixed floor ${FIX}"
print_summary 1
else
STATUS="PATCHED"
REASON="Debian-family package version ${PKGVER} meets or exceeds known fixed floor ${FIX}"
print_summary 0
fi
fi
fi
fi
# Mainline-only hint: 7.1-rc3 carries the upstream fix, but enterprise distros may backport below this.
if [[ "$KREL" =~ ^7\.1 ]]; then
STATUS="PATCHED"
REASON="running a 7.1-series kernel; upstream mainline fix is documented in 7.1-rc3"
print_summary 0
fi
# Exposure-oriented fallback.
if [[ $ESP4_AVAIL -eq 1 || $ESP6_AVAIL -eq 1 || $CFG4 -eq 0 || $CFG6 -eq 0 ]]; then
STATUS="UNKNOWN"
REASON="ESP support present or available, but exact vendor backport level could not be verified automatically"
print_summary 2
fi
STATUS="UNKNOWN"
REASON="could not determine kernel exposure"
print_summary 2
If you remember one thing.
esp4/esp6 present, and put CI runners, Kubernetes workers, bastions, VDI, and research boxes at the front of the queue. Per the noisgate mitigation SLA, deploy compensating controls such as blacklisting/unloading unused ESP modules on exposed high-risk fleets within 30 days; per the noisgate remediation SLA, move those same fleets to vendor-fixed kernels within 180 days. For single-purpose Linux servers with tightly controlled local access, this is still important, but it does not outrank internet-reachable RCEs.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.