On September 18, 2026, working local-privilege-escalation exploits were published for four Linux kernel CVEs — a set the author calls the “LPE quartet.” Each one takes an ordinary unprivileged account to root, each ships as a single reproduction script, and the release followed a coordinated hold with the Linux distributions. There are no reports of in-the-wild use yet, and the exploits are tuned to specific kernel builds. But the code is public now.
KernelScan did not scramble to catch up. We had ingested all four CVEs on the day each was published — the earliest back on August 10, thirty-nine days before the exploits existed. As of today all four are flagged Weaponized. This post is the confirmation, and a look at what the conventional severity signals said about these four in the meantime.
The four
| Name | CVE | Subsystem | KernelScan severity | In our database since |
|---|---|---|---|---|
| DirtyAH6 | CVE-2026-80844 | IPv6 IPsec (xfrm / AH6) | 7.8 High (provisional) | Sep 4 (publication day) |
| TUNderflow | CVE-2026-81000 | TUN/TAP + Open vSwitch | 7.8 High | Sep 11 (publication day) |
| PPPoEject | CVE-2026-68121 | PPPoE | 7.8 High | Aug 10 (publication day) |
| DiagSpill | CVE-2026-74469 | SCTP diagnostics (sctp_diag) | 8.8 High | Aug 15 (publication day) |
Provisional marks a KernelScan-derived score standing in where NVD has not scored the CVE. The other three carry NVD’s own base score.
All four are memory-corruption bugs reached from an unprivileged user namespace, and all
four end the same way: a rewritten /etc/pam.d/su, an installed root
credential, or a sudoers rule, then a root shell.
What the severity feeds said
A defender triaging by the usual signals would not have prioritised any of these. We checked our own Dependency-Track instance, which mirrors the National Vulnerability Database, on the morning the exploits dropped:
- DirtyAH6 (CVE-2026-80844) has no CVSS score at all. Fourteen days after publication, NVD still lists it as Unassigned. Every tool that ranks by NVD severity — Dependency-Track included — shows a root-level IPsec exploit as unrated. KernelScan filled that gap with a provisional contextual score of 7.8 High.
- EPSS rated the exploitation probability of all four as negligible. The Exploit Prediction Scoring System put them at 0.14% to 0.47% — the 4th to 40th percentile, i.e. “these will almost certainly not be exploited.” Working root exploits for every one of them are now on GitHub.
This is not a swipe at NVD or EPSS. They are probabilistic, backward-looking signals, and they lag disclosure by design. The point is narrower: if the feed you prioritise from had not scored the bug, or had scored its likelihood at near zero, you would have deprioritised a root exploit that was already written.
The real question is reachability
Four public root exploits is a headline. “Four public root exploits that reach the product you ship” is a work order — and the two are rarely the same number. Every one of the quartet needs specific kernel features compiled in, and an unprivileged user namespace to stand them up:
- DirtyAH6 needs IPv6 AH/ESP transforms (
CONFIG_INET6_AH,CONFIG_XFRM) and IOAM6. - TUNderflow needs TUN/TAP (
CONFIG_TUN), Open vSwitch (CONFIG_OPENVSWITCH), netkit and VXLAN. - PPPoEject needs PPPoE (
CONFIG_PPPOE), IP6GRE, team or bonding, AF_PACKET and FUSE. - DiagSpill needs SCTP and its diagnostic module (
CONFIG_IP_SCTP,CONFIG_INET_SCTP_DIAG).
An appliance that ships without Open vSwitch is not reachable for TUNderflow. One without the SCTP diagnostic module is not reachable for DiagSpill. One that disables unprivileged user namespaces closes the front door on all four. A config-blind severity feed cannot tell you any of that; it rates the bug, not your build. KernelScan rates your build.
Keep the urgency honest. These exploits are tuned to particular distributions and kernel revisions, they can crash or corrupt a machine, and there is no evidence of in-the-wild use so far. Weaponized means public working code exists — it raises patch priority for products that actually run the affected code. It is not a claim that you are already compromised.
What to do
If you track a kernel product in KernelScan, open it: the four now carry the Weaponized badge, and each product’s VEX tells you whether the gating config is present and reachable in your build — Affected or Not affected, per CVE, with the reason. That verdict is already in the CycloneDX VEX we push to Dependency-Track, so it travels to wherever you consume findings. If you don’t track a product with us yet, these four are a fair test of the question KernelScan exists to answer: of the twenty thousand kernel CVEs we watch, which ones reach the kernel you ship?