Short answer: CISA has added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of active exploitation, with a September 21, 2026 patch deadline for US federal civilian agencies. All three are local flaws — which is exactly why raw severity scores mislead, and why this is a triage problem before it is a patching problem.
Source: CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild — The Hacker News, September 19, 2026.
The three vulnerabilities
| CVE | CVSS | Weakness | Impact |
|---|---|---|---|
| CVE-2025-39682 | 9.8 | Improper check for unusual conditions in the TLS receive path | Memory disclosure or denial of service by a local authenticated user |
| CVE-2026-53266 | 8.8 | Out-of-bounds write in the ebtables SNAT ARP rewrite path | System compromise, DoS, or local privilege escalation |
| CVE-2025-39964 | 7.8 | Race condition allowing concurrent writes to the same AF_ALG socket | System crash or corrupted cryptographic operations |
CISA cited evidence of active exploitation when adding all three on Friday. Red Hat updated its advisories for the trio on September 19 to acknowledge the same, stating the CVEs are "high risk and there are known public exploits" and urging high-priority patching. Under Binding Operational Directive 26-04, federal civilian agencies must apply fixes by September 21, 2026.
Separately — and worth not conflating — researcher Asim Manizada recently disclosed four distinct Linux kernel local privilege escalation flaws with public exploits (CVE-2026-80844 "DirtyAH6", CVE-2026-81000 "TUNderflow", CVE-2026-68121 "PPPoEject", CVE-2026-74469 "DiagSpill"). The cluster is a reminder that local privesc research against the kernel is very active right now.
Why CVSS steers you wrong here
Look at the scores: 9.8, 8.8, 7.8. A naive queue orders by severity and works top-down. But these are local, authenticated flaws — a 9.8 that requires a local shell is a fundamentally different exposure than a 9.8 remote pre-auth RCE. The score measures technical badness, not your risk. What actually drives risk for each:
- Is the vulnerable code path reachable on your hosts? ebtables SNAT rewriting only matters where ebtables is in use (notably some container/Kubernetes networking setups).
- Who already has local access? On a single-tenant VM running one trusted app, an authenticated-local flaw is nearly moot. On a multi-tenant box, a host shared with containers of different trust levels, or a CI runner executing PR-triggered jobs, "local attacker" is a real actor.
- Is there evidence of exploitation? KEV listing says yes — the question "is anyone actually using this?" has been answered for you.
A fleet where none of the three code paths is reachable can rationally schedule these for the regular patch cycle. A fleet with thousands of multi-tenant runners cannot. Same CVEs, opposite priorities — that is the gap between severity scoring and triage.
What to do about it
- Inventory exposure, not just presence. Which hosts run kernels with the vulnerable code, and which actually use TLS offload paths, ebtables SNAT rewriting, or AF_ALG sockets?
- Rank by exposure class. Multi-tenant hosts, container nodes, and CI/CD runners jump the queue; single-tenant stateless instances can wait for the maintenance window.
- Patch inside the deadline if you're federal (BOD 26-04 requires it by September 21, 2026). Everyone else: still fast, but evidence- driven.
- Watch for chaining. Public local privesc research (see the four flaws above) means an remote foothold plus one of these equals full compromise — treat internet-facing boxes as higher exposure even for local-only CVEs.
The triage gap this exposes
Most SOCs receive each new KEV entry as another emergency with no context: is the affected service present, exposed, and already behaving strangely? Answering that per-CVE, per-fleet, by hand is exactly the workload that burns analysts out and lets the important tickets rot behind the loud ones.
This is the problem AEGIS was built for — a defender-side confidence engine for alert triage that combines evidence like KEV status, exploit availability, and your actual asset exposure into a calibrated, auditable verdict per finding, instead of a CVSS number wearing a crown. When a KEV update lands, the question is not "what does 9.8 mean?" but "which of my hosts, how exposed, patched by when?" — and that answer should be computed, not intuited.
FAQ
Are these flaws remote? No. All three require local, authenticated access to trigger. That makes exposure dependent on who can get local access — which is why multi-tenant and CI/CD hosts dominate the real risk ranking.
Does KEV listing mean my systems are being attacked? It means there is evidence of active exploitation in the wild, not necessarily against you. Check your own telemetry for the affected code paths; that distinction between "exploited somewhere" and "exploited here" is the core of evidence-driven triage.
What's the deadline? September 21, 2026 for US federal civilian agencies under BOD 26-04. For private organizations it's a strong signal to prioritize — not a compliance requirement.