Linux Kernel Privilege Escalation: 3 KEV Flaws, 4 Public Root Exploits, One Week

Within a single week in September 2026, the Linux kernel produced two things at once: three privilege-escalation bugs that CISA now lists as exploited in the wild, and four fresh proof-of-concept root exploits published with working code. The federal remediation deadline for the first three is today. The second four are on GitHub right now. This is the part of an intrusion nobody markets and everybody depends on — the step between "I have a shell" and "I own the box" — and it just got a lot cheaper.

Two Linux kernel privilege escalation events collided this week

On the morning of the KEV update, CISA added three kernel flaws to the Known Exploited Vulnerabilities catalog and set a Federal Civilian Executive Branch remediation deadline of 21 September 2026 under Binding Operational Directive 26-04, the risk-based directive that replaced the old flat 14-day KEV rule in June. Red Hat updated its advisories the same week to acknowledge known public exploits and rate the issues high risk (The Hacker News):

• CVE-2025-39682 (CVSS 9.8) — an improper-check flaw in the kernel's TLS receive path that can leak memory or crash the machine for an authenticated local user.
• CVE-2026-53266 (CVSS 8.8) — an out-of-bounds write in the ebtables SNAT ARP rewrite path that can be driven to local privilege escalation.
• CVE-2025-39964 (CVSS 7.8) — a race condition on concurrent writes to an AF_ALG socket that corrupts crypto operations or crashes the box.

Note the shape of the list. None of these is a remote, unauthenticated, click-a-link bug. All three assume the attacker is already on the machine as an unprivileged user. That is exactly why they sat unpatched long enough to be exploited: a 7.8 with "local" in the vector string loses every prioritization fight against the 9.8 on the perimeter — right up until someone gets a foothold and it becomes the only bug that matters.

The four public root exploits, and the pattern under them

Three days before the KEV additions, security researcher Asim Manizada published technical write-ups and working exploit code for four more kernel bugs, each a clean local-user-to-root path (The Hacker News):

Name	CVE	Subsystem	Mechanism	Prereq
DirtyAH6	CVE-2026-80844	IPsec AH6 (IPv6)	Trusts a routing-header field without checking address count	Unprivileged user namespaces
TUNderflow	CVE-2026-81000	TUN/TAP	One value used as both spare space and size; Open vSwitch input wraps it	Unprivileged user namespaces
PPPoEject	CVE-2026-68121	PPPoE	Use-after-free: pointer kept into a buffer a device routine can free and move	Unprivileged user namespaces
DiagSpill	CVE-2026-74469	SCTP (sctp_diag)	16-bit endpoint counter wraps at 65,536, ~8 MiB written past the buffer	None

Three of the four share one prerequisite: unprivileged user namespaces. That is the feature that lets an ordinary user create a namespace in which they hold CAP_NET_ADMIN and reach network-stack code paths — ebtables, TUN, IPsec, PPPoE — that were never meant to be attacker-driven. It is not new as an attack surface; the kernel has been leaking privilege through user namespaces since at least CVE-2014-4014, where a user namespace let a local user bypass chmod restrictions. What's new is the density: four polished exploits in one drop, three of them riding the same door.

DiagSpill is the one to sit up for. It needs no special privileges at all — an SCTP diagnostic read that any local process can trigger, wrapping a 16-bit counter to smear about 8 MiB past a heap buffer. On a host where you have disabled user namespaces as a hardening measure, DiagSpill still works.

Why "local" is the most underrated word in a CVSS vector

Prioritization frameworks are built to move the perimeter bug first, and they should — a pre-auth RCE is a worse morning than a local race condition. But the accounting quietly assumes the local step is the hard part. It isn't. In a real intrusion the attacker arrives with a foothold by definition: a web-app RCE dropped them into a service account, a leaked token got them onto a jump host, a malicious container escaped one layer. From there, the local-privilege-escalation bug is not a lower-severity footnote. It is the difference between a contained incident and domain-wide compromise.

"It's only local, we'll get to it next cycle." The attacker who phished your build agent this morning does not care that the kernel bug is local. Local is where they already are. The 7.8 you deferred is the 10 they needed.

MITRE ATT&CK files this under T1068 — Exploitation for Privilege Escalation, and it is one of the most reliably present techniques in post-breach forensics precisely because every intrusion that starts unprivileged needs it. Publishing seven usable kernel LPEs in one week doesn't create a new class of risk; it collapses the cost of a step attackers were already taking.

Remediation

A complete runbook for the seven flaws above. The KEV trio and the four public exploits overlap in fix strategy but differ in exposure, so treat them together.

1. Am I affected?

Check your running kernel and whether unprivileged user namespaces are enabled — the single most useful exposure signal here, since it gates three of the four public exploits:

uname -r                                   # running kernel
sysctl kernel.unprivileged_userns_clone    # Debian/Ubuntu knob (1 = exposed)
sysctl user.max_user_namespaces            # >0 means userns available to users
cat /proc/sys/kernel/unprivileged_bpf_disabled
# Distro CVE status (RHEL/derivatives):
rpm -q --changelog kernel | grep -iE 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

If unprivileged_userns_clone is 1 (or max_user_namespaces is non-zero) and you have not patched, DirtyAH6, TUNderflow and PPPoEject are all reachable by any local account. DiagSpill (SCTP) is reachable regardless.

2. Patch — the real fix

There is no substitute. Apply your distribution's current kernel update and reboot — a live-patched or updated-but-not-rebooted host is still running the vulnerable image:

• RHEL / derivatives: dnf update kernel && reboot, then confirm with rpm -q kernel. Follow the Red Hat errata for each CVE (Red Hat CVE database).
• Debian / Ubuntu: apt update && apt full-upgrade, then reboot. Track fixed versions in the Ubuntu CVE tracker.
• Air-gapped / long-lived hosts: stage the vendor's signed kernel package and reboot in the maintenance window; do not defer past it on internet-reachable or multi-tenant hosts.

3. Can't patch now? Compensating controls

Buy time by closing the shared door:

• Disable unprivileged user namespaces — kills DirtyAH6, TUNderflow and PPPoEject outright:

  sysctl -w kernel.unprivileged_userns_clone=0     # Debian/Ubuntu
  sysctl -w user.max_user_namespaces=0             # broad kill (breaks rootless containers/sandboxes)
  

  Persist in /etc/sysctl.d/. Test first — rootless Podman, Chromium sandboxes and some CI runners rely on user namespaces.
• Blocklist the vulnerable modules you do not use — sctp (DiagSpill), pppoe, ebtables:

  printf 'install sctp /bin/true\ninstall pppoe /bin/true\n' > /etc/modprobe.d/zh-hardening.conf
  

• Constrain foothold blast radius: enforce seccomp/AppArmor/SELinux confinement on internet-facing services so a service-account compromise cannot freely call these syscalls.

4. Hunt for compromise

There is no network IOC for a local kernel exploit — the evidence is on the host, so look there. Map to ATT&CK T1068 and T1611 (Escape to Host):

• Unexpected kernel oops / warnings in dmesg around SCTP, ebtables, TUN, or AH6 — the exploits corrupt memory and often leave a trace before they win.
• Processes that gained uid=0 without a legitimate sudo/setuid parent. Audit with:

  auditctl -a always,exit -F arch=b64 -S clone,unshare -F args=1  # userns creation
  ausearch -m avc,syscall -ts recent | grep -iE 'unshare|userns|sctp'
  

• New user-namespace creation by service accounts that never previously used them.
• Post-escalation staples: unexpected setuid binaries, new kernel modules (lsmod diff against a known-good baseline), tampered /etc/passwd, cron/systemd persistence added by root.

5. Eradicate + verify

If you find evidence of a successful escalation, assume the host is fully owned:

1. Isolate and image the host for forensics before you change it.
2. Rotate every credential, key, and token that touched the box — service-account secrets, SSH keys, cloud IAM, tokens in the container's environment.
3. Rebuild from a known-good image, then patch, then reboot. A rooted host cannot verify its own cleanliness — a competent implant survives file cleanup.
4. Confirm the fix on the rebuilt host: rpm -q kernel / dpkg -l linux-image-*, sysctl state re-hardened, and re-run your foothold-to-root check against it.

Where this leaves you, and where Zero Hunt fits

The honest problem this week exposes is not any single CVE — it is that the local-escalation step is systematically under-tested. Scanners flag the perimeter bug and rank the 7.8 "local" flaw as low priority. Nobody proves whether, on your kernel build and your service confinement, a realistic foothold actually chains to root.

That proof is what Zero Hunt's AI generative pentest is built to produce. The 10-agent swarm doesn't stop at "a local kernel LPE exists." The Post-Exploit and Pivot agents take a realistic low-privilege foothold — a web-app compromise, a container escape — and run the escalation-to-root and lateral movement end-to-end against your actual hosts, writing a per-target exploit with a local LLM rather than pulling public PoC code, every skill backtested in the AI Gym before it touches production, and each finding ECDSA-signed into a chain-of-custody record. The output isn't a deferred 7.8 line; it's "this foothold reached root on this host, here's the path." And when the escalation runs, the credential theft and lateral fan-out that follow it are exactly what the AI Traffic Analysis model reads on the wire — while it's happening, not in tomorrow's log review.

CVSS can score a bug in isolation. It cannot tell you whether the local step — the one every real intrusion depends on — is reachable in your environment. That is a question you have to answer by running the chain. Talk to us about running it before the next four exploits drop.