TL;DR - CISA added three Linux kernel flaws to its Known Exploited Vulnerabilities catalog on 18 September 2026, citing evidence of active exploitation, and the same day a researcher published working local-root exploits for four more kernel bugs, fixed upstream but public now. Three of the four need unprivileged user namespaces enabled; DiagSpill needs the SCTP module and non-default options rather than user namespaces. What you need to do: match your running kernel against your distribution's advisory and patch hypervisors, container hosts and CI runners first.
I ran uname on the box I was working on while drafting this. It came back 7.2.2-1-cachyos. The full fix set lands in 7.2.4. That is the useful thing about weeks like this one: the answer is not in a spreadsheet somewhere, it is one command away, and it is frequently not what the spreadsheet says.
There is a second reason I checked rather than assumed. Local root on a Linux box stopped being a modest finding a while ago. Most of the Linux systems I look at are not laptops. They are hypervisors running a dozen guests, container hosts running a hundred workloads, or CI runners holding deployment credentials for everything downstream.
On those boxes, one shell is not one shell. It is the key to whatever the box can reach.
By the numbers
| Item | Detail |
|---|---|
| KEV additions | 18 September 2026 (CISA, three Linux kernel CVEs) |
| CVE-2025-39682 | TLS receive path. NVD lists 9.8 network and 7.1 local - the vector decides |
| CVE-2026-53266 | CVSS 8.8, ebtables SNAT ARP rewrite, out-of-bounds write |
| CVE-2025-39964 | CVSS 7.8, AF_ALG socket race condition, DoS or crypto corruption |
| Public exploits released | 18 September 2026 (four local-root flaws) |
| Researcher | Asim Manizada, reported to kernel security team mid-July 2026 |
| FCEB remediation deadline | 21 September 2026 (BOD 26-04) |
| Fixes first complete in | 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50, 7.2.4 |
| Age of the underlying bugs | 10 to 21 years |
| Reported real-world attacks on the four | None at the time of writing |
What CISA added, and why the score order misleads
The three KEV additions are separate flaws in the same subsystem family, added together on 18 September.
CVE-2025-39682. An improper check for unusual or exceptional conditions in the TLS receive path: a zero-length record pulled from the receive list can leak kernel memory or crash the host. NVD carries two scores for this one, and the gap between them is the story: 9.8 CRITICAL on the network vector with no privileges required, and 7.1 HIGH on the local vector with low privileges. Same bug, two exposure models. Which one applies to you depends on whether the host handles TLS traffic from networks you do not control.
CVE-2026-53266, CVSS 8.8. An out-of-bounds write in the ebtables source NAT ARP rewrite path. A local attacker can cause unintended system behaviour, a denial of service, or local privilege escalation. This is the one of the three that reaches privilege escalation in the description, and privilege escalation is what turns a foothold into a host compromise.
CVE-2025-39964, CVSS 7.8. A race condition allowing concurrent writes to the same AF_ALG socket, letting a local attacker crash the system or corrupt cryptographic operation results. The impact is a denial of service and data integrity rather than escalation.
Read those three together and the score order does not match the operational priority. The highest-scoring flaw is a memory disclosure and denial of service. The middle one is the privilege escalation. If you triage by CVSS alone you will spend your window in the wrong order.
The second thing worth noticing is the timing of the Red Hat response. The Red Hat advisory pages for all three carry an update timestamp of 02:00 UTC on 19 September, hours after the KEV addition, and that update acknowledges active exploitation. Its advisory language for the TLS flaw is direct: this CVE is high risk and there are known public exploits leveraging it, address it with high priority. When a distributor moves that fast and uses that wording, the exploitation evidence is not speculative.
There is no public detail on how the three are being exploited, and no indication yet whether they are chained together in a single attack. Federal civilian executive branch agencies were recommended to remediate by 21 September under Binding Operational Directive 26-04. That deadline is a policy construct rather than a technical one, but it is a reasonable default for anyone whose Linux estate is internet-adjacent.
The four public exploits, and the prerequisite that decides your risk
The second half of the week is a different story with a familiar shape. Asim Manizada reported four local privilege escalation flaws to the kernel security team in mid-July, held disclosure while distributions shipped fixes, and published his technical write-up with working exploit code on 18 September.
All four are memory-safety bugs in kernel networking code. All four are fixed in current kernels. The exploit code is public, is tuned to specific kernel builds, and can crash a machine, so it is intended for isolated test systems rather than production.
| Flaw | CVE | Kernel area | Local prerequisite | Remote reach |
|---|---|---|---|---|
| DirtyAH6 | CVE-2026-80844 | IPsec AH6 (IPv6) | Unprivileged user namespaces | Crash only, and only on a host routing IPv6 with a transport-mode Authentication Header |
| TUNderflow | CVE-2026-81000 | TUN/TAP virtual network devices | Unprivileged user namespaces | No |
| PPPoEject | CVE-2026-68121 | PPPoE | Unprivileged user namespaces | No |
| DiagSpill | CVE-2026-74469 | SCTP (sctp_diag) | None | Crash only, and only with non-default SCTP options enabled |
The prerequisite column is the useful part of that table. Three of the four require unprivileged user namespaces, the feature that lets an ordinary user act as root inside a private sandbox. Many distributions enable it by default, and it is what gives an attacker the network privileges the exploits need. If unprivileged user namespaces are disabled on a host, the ordinary-user path to DirtyAH6, TUNderflow and PPPoEject is closed.
DiagSpill is the exception and it is the one to read twice. It needs no user namespaces and no special privileges, just the SCTP networking module and the non-default options its trigger uses. Its trigger is a 16-bit counter tracking connection endpoints: at the 65,536th endpoint it wraps to zero, the reporting code reserves no space but copies the full list, and roughly 8 MiB lands past the end of the buffer.
On remote reachability, the write-up is more restrained than the headlines suggest. DirtyAH6 can crash a host that acts as an IPv6 router or gateway and adds an IPsec Authentication Header in transport mode. DiagSpill can crash a host only when certain SCTP options, off by default, are enabled. Manizada reached remote root with DirtyAH6 only in his own lab and only after shaping memory on the target first, describing that from a purely remote position as looking extremely difficult without ruling it out. For DiagSpill he sees no path to remote root at all. He also noted the flaws could in theory allow a container escape, but did not build one.
So the honest reading is: these are local privilege escalation flaws with public code, not a remote unauthenticated worm. Their significance depends entirely on what a low-privileged shell on your box is worth.
Two different problems sharing a week
It is easy to read the KEV additions and the four exploits as one event. They are not connected.
The KEV trio is about flaws with evidence of exploitation in the wild. The four exploits are about flaws with public proof-of-concept code and no reported real-world attacks. What separates the two lists is time: one is already being used against systems, the other is about to become easier to use.
The practical consequence is that the two sets want different responses:
- The KEV trio wants speed. Exploitation is happening. The relevant question is how fast you can get a rebooted kernel onto the hosts that matter.
- The four exploits want coverage. No exploitation is reported, but the code is public. The relevant question is whether unprivileged user namespaces are enabled on hosts where they do not need to be, because that setting is the difference between a mitigated host and an exposed one.
Treating them as one problem usually produces one action, which means one of the two goes unhandled.
Why Linux kernel local privilege escalation matters more than the CVSS suggests
A CVSS 7.8 local privilege escalation scores lower than a remote unauthenticated flaw, and the calculator is right to score it that way. The scoring model asks what the attacker needs, and a local flaw asks for a foothold.
The operational reality in most ANZ environments is that the foothold already exists or is easy to obtain. Multi-tenant hosts have other tenants. CI runners run code that arrived from somewhere. Container platforms have workloads with network access. Jump hosts have shared accounts. The frontier between "has a shell" and "has root" is doing less work than the scoring model assumes, which is why the local classification should not be read as reassurance.
There is also the persistence dimension. Root on a hypervisor is root on every guest that hypervisor runs, at least in terms of what can be reached from the host. Root on a container host is root over the workloads. A local escalation on the right box is a much shorter path to the interesting data than a local escalation on a workstation.
The AI-assisted discovery footnote
One detail in the write-up deserves more attention than it has received. Manizada found the four flaws with an AI-assisted process that builds a map of how the kernel handles memory and reasons about its layout. The kernel's own fix commit for DirtyAH6 includes an "Assisted-by" line crediting his custom AI tooling.
That is a kernel commit line, which means the tooling was involved enough in identifying the bug that the maintainers recorded it. He also disclosed OVSwrap in July, and said this batch likely ends the public phase of his AI-assisted bug hunting.
I keep landing on the same question when I see this pattern. If four decade-old kernel memory bugs can be found by one researcher with custom tooling and a write-up at the end, the backlog of similarly old memory bugs is not small, and the cost of finding them is falling. That does not change what you do on Tuesday. It does change how you think about the assumption that a kernel flaw has probably been found already.
What to do this week
- Run
uname -ron every Linux host. Not the version in your asset register and not the version in the deployment manifest. The running kernel. Check the ones you think you know first, because those are the ones where a mismatch will annoy you. - Check your distribution's advisory, not the upstream version list. The releases carrying the complete fix set are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4 from the mainline project. Debian, Ubuntu, Red Hat and SUSE use their own version numbering and add fixes on their own schedule. Confirm your vendor has shipped an update containing all four, because a kernel can be newer than your current one and still be missing one of them.
- Order by what the host can reach, not by hostname. Hypervisors come first - a Proxmox or ESXi host sits upstream of everything it hosts - then container hosts, CI runners, jump boxes, and anything holding deployment credentials. A developer workstation running the same vulnerable kernel is lower priority than the runner that deploys your production environment.
- If you cannot patch immediately, disable unprivileged user namespaces. That closes the ordinary-user path to DirtyAH6, TUNderflow and PPPoEject on hosts that do not need the feature. It does not stop DiagSpill, and it does not stop anything that already holds network-admin privileges. Test it, because some container runtimes and rootless tooling depend on it.
- Disable the subsystems you do not use. AH6, TUN/TAP, PPPoE and SCTP. Most enterprise hosts use none of the four. Removing the attack surface is cheap when the feature is not in use. Manizada recommends patching instead of feature-disabling, on the grounds that other paths to the same flaws may exist, so treat this as interim rather than finished.
- Check whether SCTP is loaded where it should not be. DiagSpill has no user-namespace prerequisite, which makes it the one that does not care about your hardening posture. If the module is present on hosts that have no reason to speak SCTP, that is worth a change record.
- Plan the reboot as well as the patch. Kernel updates need the host to restart to take effect. For hypervisors that means evacuating guests or scheduling an outage window, which is the step that turns a one-week patch into a two-week patch when nobody plans it. Start the conversation with the people who own the maintenance window on the day the update lands.
- Tell your developers why their runner rebooted. If you patch a CI fleet, expect build failures from the restarts. A sentence in the internal channel beforehand is cheaper than a morning of investigation afterwards.
Frequently asked questions
Are these the same vulnerabilities? No. Three flaws were added to CISA's known-exploited catalog on 18 September 2026 with evidence of active exploitation. Four different flaws had public exploit code released on 18 September 2026 with no reported real-world attacks. They share a week and a subsystem family, not an attack chain.
Which kernel version fixes everything? The first stable releases carrying the complete set are 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 and 7.2.4. Distributions use their own numbering, so verify against your vendor's advisory rather than comparing upstream numbers to a distro version string.
Does DiagSpill need unprivileged user namespaces? No, and that is what separates it from the other three. It requires no user namespaces, only the SCTP module and the non-default options its trigger uses. Disabling user namespaces does not mitigate it.
Can any of these be exploited remotely? Not to root, on the evidence published. DirtyAH6 can crash a host that routes IPv6 and adds a transport-mode IPsec Authentication Header, and only that. DiagSpill can crash a host with non-default SCTP options enabled. The researcher reached remote root only in his own lab after shaping memory on the target, and he sees no path to remote root for DiagSpill.
Is it safe to just disable unprivileged user namespaces and wait? It closes three of the four, and it does not close DiagSpill. It can also break rootless containers, some build tooling and certain sandboxed applications, which means testing rather than rolling it out blind. Patching is the remediation.
Does this affect my distribution's kernel? Yes, and the vendor question is the one that matters. Every supported enterprise distribution builds its kernel from one of the affected long-term lines, so the vulnerable code is in your kernel, and what differs is whether your vendor has shipped the fixes and which version numbers it uses. Check your distribution's advisory rather than comparing against the upstream release list.
We run container platform kernels managed by the vendor. Do we need to do anything? Yes, but the action is different. Confirm which kernel the platform's host nodes are actually running and whether the platform version you are on incorporates the fixes. Managed layers still sit on a real kernel, and that kernel is still your exposure.
My Take
Two things happened this week and I think the second one is more interesting than the first, even though the first will get more attention.
The KEV additions are the sort of story the industry handles well. There is evidence of exploitation, there is a deadline, there is a catalog entry, and the machinery of vulnerability management knows exactly what to do with it. It is a rate problem, and rate problems get solved when someone protects the maintenance window.
The public exploit release for four decade-old kernel flaws is the story about how the work is changing. Four memory-safety bugs, 10 to 21 years old, in code that millions of systems run, found by one researcher with custom AI tooling and acknowledged in a kernel commit line. Nobody exploited them in the wild. They were found because the cost of finding them fell, not because anyone was chasing them.
That means the useful assumption has changed. The old assumption was that a kernel bug found by a determined researcher was probably already known, or already being used, or overrated. The new assumption is that a class of old, unremarkable, unpatched-by-default memory bugs is going to be enumerated systematically over the next few years, by people who are getting better at it and by tooling that is getting more available.
I am not going to pretend that means you should patch weekly. Most of my Linux hosts do not need a weekly reboot and would resent one. What it does mean is that the kernel version question is going to move up the list, and the estates where the running kernel is a thing people actually track are going to be much less painful to defend than the ones where it is a line in a spreadsheet that nobody has verified since the box was built.
One command. It was the first thing I did.
Further reading
- CISA: adds known exploited vulnerabilities to catalog (18 September 2026)
- CISA: adds one more exploited vulnerability to catalog (CVE-2025-39682, same day, separate alert)
- NVD: CVE-2025-39682 - both base scores and the vectors behind them
- CISA: BOD 26-04 implementation guidance (the three-day remediation threshold)
- Asim Manizada: LPE quartet technical write-up with working exploits (18 September 2026)
- Red Hat advisories: CVE-2025-39682, CVE-2026-53266 and CVE-2025-39964 (updated 02:00 UTC, 19 September 2026)
- SecureInSeconds: CISA added four actively exploited flaws - which order to burn the window in
- SecureInSeconds: The Linux bridge STP vulnerability and the patch that fixes it
Mathew Clark / Founder, SecureInSeconds / Currently: of the view that the running kernel is a line item worth checking weekly rather than annually, which is a habit I am still building
