CISA's three Linux kernel KEV entries and the four public root exploits are seven different flaws

Seven flaws, not three

Three hundred and eighty six days separate the stable kernel release that fixed CVE-2025-39682 from the day the US Cybersecurity and Infrastructure Security Agency said the flaw was being exploited. Linux 6.12.44, which carries the fix, was released on 28 August 2025. CISA added the CVE to its Known Exploited Vulnerabilities catalogue on 18 September 2026, alongside CVE-2025-39964 and CVE-2026-53266, with a remediation due date of Monday 21 September.

The same day, a security researcher published working local root exploits for four Linux kernel flaws, named DirtyAH6, TUNderflow, PPPoEject and DiagSpill. Two Linux kernel stories, one Friday. The obvious inference is that they are the same story.

They are not. Set the two lists side by side and no identifier appears on both. CISA's three are CVE-2025-39964, CVE-2026-53266 and CVE-2025-39682. The four with public exploits are CVE-2026-80844, CVE-2026-81000, CVE-2026-68121 and CVE-2026-74469. Seven distinct CVEs, in seven distinct parts of the kernel, on two separate clocks. Neither list mentions the other.

That is the finding this briefing is built on, and it matters operationally, because the two sets are in very different states. The three CISA says are being exploited are mostly patched in the distributions UK estates actually run. The four with public exploit code, for which nobody has reported any real world use, are in several cases not patched at all.

What CISA said, and what it did not

The three entries are identical in every field that matters except the description. Each carries a due date of 21 September 2026, three calendar days after the date added. Each is marked as requiring forensic triage. Each records known ransomware campaign use as Unknown. Each carries the same required action text, which points at CISA's Binding Operational Directive 26-04.

BOD 26-04 is the reason the deadline is three days rather than the three weeks people remember. Issued on 10 June 2026, it revoked BOD 22-01, the 2021 directive that created the KEV catalogue, and replaced the old flat clock with a risk table driven by four variables: whether the asset is publicly exposed, whether the CVE is in the KEV catalogue, whether an adversary can automate exploitation, and how much control exploitation gives. The shortest cell in that table is three days plus a forensic triage of the asset, which the directive defines as an assessment of whether the system is already compromised. All three entries landed in it.

Alongside the catalogue entries, CISA's own vulnerability enrichment records a decision point set for each, timestamped 18 September 2026: exploitation active, technical impact total. CVE-2025-39682 is additionally marked automatable yes; the other two are marked no.

What the CISA KEV entries of 18 September 2026 state and do not state. Source: the catalogue JSON, version 2026.09.18, and the CISA enrichment records in NVD.

Question	Stated on the record	Not stated
Is it exploited?	Yes, exploitation status active for all three	When exploitation began, or when CISA learned of it
Who is doing it?	Nothing	Actor, campaign, sector or country
Ransomware involved?	Known ransomware campaign use: Unknown	Whether that means no, or merely unconfirmed
What does an attacker gain?	Technical impact: total	Whether any observed attack reached root
Is the product supported?	Two entries carry an end of life warning	Which distributions or builds are meant
What must be done?	Patch by 21 September and run a forensic triage	Anything a defender could use to hunt for prior compromise

The inclusion bar itself is public and it is evidential rather than predictive. CISA's criteria page says a vulnerability qualifies when there is reliable evidence it has been actively exploited in the wild, and explicitly rules exploitability, including the existence of a public proof of concept, out of the test. That cuts in an awkward direction this week. The three flaws with no public exploit are in the catalogue. The four with working public exploits are not.

The three in the catalogue

All three are local privilege escalation, which is to say an attacker needs to be running code on the machine already. What each gives back, per the kernel's own commit messages and CISA's impact rating, is total control of the host.

The three Linux kernel CVEs added to the KEV catalogue on 18 September 2026. Subsystems and file paths from the Linux kernel CNA records; fixed versions from the NVD version ranges.

CVE	Subsystem and bug class	First fixed upstream
CVE-2025-39964	AF_ALG userspace crypto socket, race condition on concurrent writes, CWE-362	5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9
CVE-2025-39682	Kernel TLS receive path, zero length record mishandled, CWE-754	6.1.149, 6.6.103, 6.12.44, 6.16.4
CVE-2026-53266	Bridge netfilter ebtables SNAT target, out of bounds write, CWE-787	5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36, 7.0.13

CVE-2025-39964 is a race in the kernel's userspace crypto interface. Two concurrent writes to the same AF_ALG socket interleave unpredictably and leave the socket's internal state inconsistent. The fix, by Herbert Xu, adds an exclusive write flag. It landed in Linux 6.12.49 on 25 September 2025, which is 358 days before the catalogue entry. Reaching it needs an AF_ALG socket, which any local process can open where the kernel's crypto user API is built in.

CVE-2025-39682 is in the kernel TLS receive path. A zero length record pulled from the receive list bypasses the record type handling in the receive call, so later records are processed with the wrong zero copy and queuing assumptions. The fix, by Jakub Kicinski, shipped in Linux 6.12.44 on 28 August 2025. It needs kernel TLS to be in use, which on a modern estate means offloaded TLS termination or anything using the kTLS path.

CVE-2026-53266 is the youngest and the most interesting for anyone running containers. The ebtables source NAT target on a bridge optionally rewrites the ARP sender hardware address, and it did so through a write at an offset relative to the packet data without first making that range writable. Where the range sat in a non linear socket buffer fragment backed by a spliced file page, the write went straight into that page. The fix shipped in Linux 6.12.94 on 19 June 2026, 91 days before the catalogue entry. Bridge netfilter is not an exotic corner: it is the path container networking runs through.

The four with public exploits

The second story is a coordinated disclosure that ran its course. Asim Manizada reported four flaws to the kernel security team in mid July 2026, the fixes landed over the following weeks, and by agreement with the Linux distributions list he published his analysis and proof of concept code on 18 September. He states that the underlying mistakes are between 10 and 21 years old, and that he found them with an AI assisted process; the kernel's fix for DirtyAH6 carries an assistance credit for his tooling. The Hacker News, reporting the release, says there are no reports of real world use of any of the four.

The four Linux kernel flaws with public local root exploits published on 18 September 2026. Names, prerequisites and first fixed releases from the researcher's write up; subsystems confirmed against the Linux kernel CNA records.

Name and CVE	Subsystem	What the attacker needs first
DirtyAH6, CVE-2026-80844	IPsec Authentication Header for IPv6	Unprivileged user namespaces, or CAP_NET_ADMIN and CAP_NET_RAW in a namespace it controls
TUNderflow, CVE-2026-81000	TUN and TAP virtual network devices	Unprivileged user namespaces, or CAP_NET_ADMIN, plus a path that propagates oversized headroom
PPPoEject, CVE-2026-68121	PPP over Ethernet	Unprivileged user namespaces, or CAP_NET_ADMIN
DiagSpill, CVE-2026-74469	SCTP socket diagnostics	Nothing beyond SCTP and sctp_diag being available

DiagSpill is the one to read twice. The researcher is explicit that it requires no user namespaces and no special capabilities at all. An SCTP association can hold 65,536 peer transports while the counter that tracks them is 16 bits wide, so the 65,536th wraps it to zero; the diagnostics path then reserves no space for the peer list and copies the whole thing anyway, writing roughly 8 MiB past the end of its buffer. Any local user on a host where the SCTP modules are loadable can reach it.

The common mitigation advice, which is to switch off unprivileged user namespaces, therefore covers three of the four and not the fourth. The researcher says so himself, and adds that disabling namespaces does not protect against a container or process that already holds the network administration capability. He recommends patching over feature disabling on the grounds that other paths to the same bugs may exist.

Where the fix actually is

Upstream version numbers are not what your servers run. The first upstream stable releases carrying all four of the exploited flaws are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Distributions backport on their own schedules, and the picture on 19 September 2026 is uneven in a way that inverts the headline.

Distribution fix state on 19 September 2026, from the Debian security tracker, the Ubuntu CVE tracker and Red Hat's CVE data. Fixed on the record means a package version or advisory is named.

CVE	Fixed on the record	Not fixed on the record
CVE-2025-39964, in KEV	Debian bullseye to sid; Ubuntu xenial through plucky	Red Hat Enterprise Linux 7, 8, 9 and 10 all still marked Affected
CVE-2025-39682, in KEV	Debian bookworm and trixie; Ubuntu noble and plucky; RHEL 9 and 10 via RHSA-2025:16880 and RHSA-2025:16904	Nothing outstanding on the trackers checked
CVE-2026-53266, in KEV	Debian bullseye to sid; RHEL 8 and 9 via RHSA-2026:39083 and RHSA-2026:36645; Ubuntu resolute	Ubuntu focal needed, jammy and noble pending; RHEL 10 Affected
CVE-2026-80844, DirtyAH6	Debian bookworm security via DLA-4777-1; Debian forky and sid	Debian trixie, the current stable; Ubuntu bionic to noble all needed; no Red Hat record exists yet
CVE-2026-81000, TUNderflow	Debian sid only	Debian bookworm, trixie and forky; Ubuntu bionic to resolute all needed; RHEL 7 to 10 Affected
CVE-2026-68121, PPPoEject	Debian bookworm, trixie, forky and sid	Ubuntu bionic, focal, noble, xenial and trusty needed; RHEL 7 to 10 Affected
CVE-2026-74469, DiagSpill	Debian bookworm, trixie via DSA-6466-1, forky and sid	Ubuntu bionic, focal and noble needed; RHEL 7 to 10 Affected

Two rows are worth pausing on.

First, CVE-2025-39964 has no Red Hat fix. It is in the KEV catalogue with a due date of Monday, CISA rates its technical impact as total, and on Red Hat's own CVE page the state for Red Hat Enterprise Linux 7, 8, 9 and 10 is Affected, meaning no errata has shipped. Red Hat rates it Moderate. A US federal agency running RHEL cannot meet Monday's deadline by patching, because there is nothing to install. The directive's answer is mitigation or removal from the network, but the friction is real and it is not the agency's fault.

Second, Debian's current stable release is vulnerable to two of the four public exploits. Trixie ships linux 6.12.107-1. DirtyAH6 was first fixed in 6.12.108 and TUNderflow in 6.12.109. The oldstable release, bookworm, is in better shape for DirtyAH6 than stable is, because DLA-4777-1 moved it to 6.1.187, which carries that fix. TUNderflow is unfixed across bookworm, trixie and forky on the tracker; only unstable has it. The same pattern holds on Ubuntu, where the tracker lists TUNderflow as needed on every supported release from bionic to resolute.

The severity scores disagree with the catalogue

If your patch policy is keyed to a severity number, look at what that number said about CVE-2025-39964 before Friday.

Severity assigned to CVE-2025-39964 by four sources, all fetched on 19 September 2026. The Linux kernel CNA is the assigner; CISA rates technical impact separately through its enrichment programme.

Source	Rating	What it implies for a 14 day patch rule
Canonical, Ubuntu CVE tracker	CVSS 3.3, priority medium	Below any common threshold
NVD primary, NIST	CVSS 5.5 medium, availability impact only	Below the Cyber Essentials threshold of 7
Red Hat	CVSS 5.5, threat severity Moderate	Below the threshold, and no fix shipped
Linux kernel CNA	CVSS 7.8 high	Above the threshold
CISA, 18 September 2026	Exploitation active, technical impact total	Three day federal clock, forensic triage required

A spread of 3.3 to 7.8 on one flaw is not a scandal, it is what happens when different assigners model different deployment assumptions. But it destroys the idea that a single number can carry a patch decision. Two of the four scores sit below the line that a Cyber Essentials assessor, or most internal policies, would use to trigger the urgent window. CISA's read of the same flaw is that an attacker who exploits it takes total control and that this is happening now.

The same disagreement runs the other way on CVE-2025-39682, where the kernel CNA assigned 9.8 with a network attack vector while NVD's primary score is 7.1 with a local one. Those are not small differences of opinion. They are different claims about whether an attacker needs to be on the box.

There is a friendly label doing damage here too, and it is the phrase local privilege escalation. It sounds like a constrained, second order problem, and the word local reads to a triage queue as a control. It is not a control. It is a statement about where the attacker has to be standing, and the whole of the modern intrusion economy is in the business of putting them there.

A foothold is the cheap part

Consider how an ordinary user account on one of your Linux servers actually gets taken. A phished developer's SSH key. A malicious npm or PyPI package executing in a build. A web application flaw that yields code execution as the service account. A container image pulled from somewhere nobody audited. A CI runner that accepts jobs from forked pull requests. None of these needs a kernel bug, and none of them is rare. They are the routine output of every incident report published this year.

What local privilege escalation does is convert that foothold from an incident into a compromise. It is the step between the attacker having a process and the attacker having the machine, and on a shared machine it is also the step between having the machine and having everyone else's.

The container case is where the arithmetic has genuinely changed. The researcher is careful: he says the primitives could in theory allow a container escape, and that he did not build one. That is the honest position and this briefing will not improve on it.

But the effort required to bridge that gap is now documented. In June 2026 a container security practitioner writing as raesene described taking a published Linux local root proof of concept and, with a large language model and a virtual machine harness for validation, producing a working container breakout. The stated cost was two hours and about thirteen dollars in tokens. His conclusion is blunt: where untrusted images run, or where an attacker might execute code inside a container, the container should not be relied on for isolation at all. That is one practitioner's account and one data point, not a measurement. It is also a number that no security team can pretend it has not seen.

What Monday's deadline is, and what it is not

Be precise about the 21 September due date, because it will be quoted loosely all weekend. BOD 26-04 binds Federal Civilian Executive Branch agencies of the United States government and the federal information systems they operate or have operated on their behalf. It explicitly does not reach statutorily defined national security systems, and it does not apply to contractors unless their contract says so. It has no force in the United Kingdom, over any UK organisation, at all.

What it does provide is a public, dated, government assessment that three named kernel flaws are being exploited right now and that exploitation yields total control. That assessment is free, and it is as good a risk input as most UK organisations will get this year.

The UK clock that does bind is Cyber Essentials. Version 3.3 of the Requirements for IT Infrastructure, in force since April 2026, states that software must be updated, including vulnerability fixes, within 14 days of release where the update fixes vulnerabilities the vendor describes as critical or high risk, where it addresses vulnerabilities with a CVSS version 3 base score of 7 or above, or where the vendor gives no severity details at all.

Read that third limb carefully, because it is the one that saves you. A distribution kernel update almost never comes with a per flaw severity breakdown, and the scheme's own caution note says that where a bundled update covers any critical or high risk issue, the whole update falls inside the 14 day window. So in practice a distribution kernel security update is a 14 day item regardless of what any individual CVE scored. An organisation that skipped a kernel update because the headline CVE was rated Moderate has a certification problem as well as a security one.

The two clocks in this story, from BOD 26-04 and Cyber Essentials Requirements for IT Infrastructure v3.3.

Clock	What it requires	Who it binds
CISA BOD 26-04	Remediate or mitigate within 3 calendar days of the catalogue entry, and run a forensic triage of the asset	US federal civilian agencies only. No UK effect
Cyber Essentials v3.3	Apply critical or high risk updates within 14 days of release, including updates with no stated severity	Any UK organisation holding or seeking certification
Neither	Any obligation to check whether the flaw was exploited on your estate before you patched it	Nobody, which is the gap

What to do before Monday

In order. The first three items are for this weekend; the rest can wait for the working week.

# Running kernel, per host, against the fixed versions in the tables
uname -r

# Is a newer kernel installed but not booted? Debian and Ubuntu
dpkg -l 'linux-image-*' | grep '^ii'

# Red Hat family
rpm -q --last kernel | head -3

# Are unprivileged user namespaces enabled?
sysctl kernel.unprivileged_userns_clone 2>/dev/null
sysctl user.max_user_namespaces

# Is SCTP loadable? (DiagSpill needs no namespaces and no capabilities)
modprobe -n -v sctp; modprobe -n -v sctp_diag

The question that exposes the gap

The three flaws CISA says are being exploited are, for most UK estates, already fixed by the distribution. The four with working public exploit code are, for several UK estates, not. If your patch process is driven by catalogue membership and severity scores, it has spent this weekend on the set that is already closed and ignored the set that is open.

That is not an argument against the KEV catalogue, which is one of the most useful things any government produces for defenders. It is an argument about what a catalogue can be. KEV is a record of what has been seen. It is not a forecast, and it was never built to be one. A flaw arrives in it after the evidence does, which means that for every entry there is a period, in the cases here measured in hundreds of days, when the thing was being used and nobody outside told you.

So the question for Monday morning is not whether you met a deadline that does not apply to you.

It is this: on how many of your Linux hosts could you prove, from evidence you currently hold, that a local user did not become root at any point in the 386 days between the fix and the catalogue entry? If the honest answer is none, then the patch was never the control you thought it was, and the logging is the thing to fix next.