Three Exploited Linux Kernel Flaws Land in CISA's KEV Catalog

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Infrastructure security for US and EU enterprise teams

The short answer

What CISA flagged

On September 18, 2026, the US Cybersecurity and Infrastructure Security Agency added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, citing evidence of exploitation in the wild. Under Binding Operational Directive 26-04, federal civilian agencies must remediate all three by September 21 — and, unusually, CISA marked every one as requiring forensic triage, meaning agencies must actively investigate exposed assets for signs of compromise rather than treating patch installation as the end of the job.

The most severe is CVE-2025-39682, rated CVSS 9.8. It is an improper check for an exceptional condition in the kernel TLS (kTLS) receive path: a corner case in which a zero-length record retrieved from the internal rx_list bypasses the intended recvmsg() record-type handling, leading to memory disclosure or denial of service. Red Hat's advisory states the issue is high risk and that public exploits leveraging it already exist. CVE-2026-53266 (CVSS 8.8) is an out-of-bounds write in the netfilter bridge ebtables Source NAT path, triggered during ARP sender hardware-address rewrite operations, that can cause unintended behavior, a crash, or local privilege escalation. CVE-2025-39964 (CVSS 7.8) is a race condition allowing concurrent writes to the same AF_ALG socket — the kernel's crypto-from-userspace interface — which can crash the system or corrupt the result of a cryptographic operation, creating both availability and data-integrity risk.

These are not related to one another and there is no evidence of a single coordinated attack chain; they are three independent kernel weaknesses that happened to earn KEV entries the same day. Distributions moved quickly — Red Hat, for example, refreshed its advisories on September 19 — and the remediation for all three is the same: install the fixed kernel from your distribution and reboot, or apply a live-patch where supported.

Why "local" is not "low risk"

Two of these flaws need local access, and the third affects local authenticated users, which can read as reassuring — until you remember what "local" means in a cloud-native estate. A container that an attacker broke out of, a foothold gained from a web-application exploit, a compromised dependency running in a CI job, or a low-privilege service account are all "local." In practice, the initial intrusion is rarely the goal; the escalation from that foothold to root on the host is. CVE-2026-53266's out-of-bounds write is exactly that kind of privilege-escalation primitive, and CVE-2025-39964's ability to corrupt cryptographic results undermines the integrity guarantees other controls depend on.

The kTLS flaw raises a different flag. Kernel TLS offloads encryption of network streams into the kernel for performance, and it is used by high-throughput services and proxies. A remotely reachable path that ends in memory disclosure or a crash of that subsystem is the kind of primitive attackers chain into larger campaigns, which is likely why it drew a 9.8 and a note about existing public exploits. The lesson that recurs with kernel CVEs is that severity is about what an attacker can reach from where they already are — and in multi-tenant infrastructure, "already inside a container on a shared node" is a common starting point, not a remote one.

What it means for US & EU software teams

First, a kernel CVE is a fleet event, not a server event. The kernel is the single component your VMs, containers, and CI runners all share, so exposure scales with your infrastructure rather than with one application. That changes the remediation shape: you are not patching a service, you are rolling kernels across every host and node, rebuilding the container base images that inherit that kernel through the host, and rebooting or live-patching without dropping production traffic. Teams whose cloud and DevOps platform already treats kernel updates as an automated, tested pipeline will absorb this in a day; teams that patch kernels by hand will discover how many hosts they had forgotten.

Second, the three-day clock is a test of inventory and orchestration, not of goodwill. When CISA attaches forensic triage to a KEV entry, patching alone is explicitly not enough — you have to be able to say which hosts were affected, when they were patched, and whether any were touched beforehand. That demands current asset data, centralized logging, and the ability to schedule an out-of-band reboot across the estate on short notice. Those are capabilities you build in advance; you cannot improvise them inside a 72-hour window.

Third, this is a compliance and reporting event for regulated teams. A root-capable kernel flaw with confirmed exploitation lands squarely inside NIS2 and DORA expectations in the EU for security of processing and prompt, documented remediation, and inside SOC 2 and HIPAA obligations for US teams in finance and health. Being able to produce the patch timeline, the affected-asset list, and the triage findings is the evidence auditors and regulators ask for first — and it is far easier to generate when patch management and logging are already engineered rather than reconstructed after the fact.

What to do now

1. Inventory the fleet. Enumerate every Linux host, cluster node, and CI runner and map running kernel versions. The boxes missing from your inventory are the ones that stay unpatched past the deadline.
2. Patch and reboot. Install the fixed kernel from your distribution and reboot, or apply a live-patch where your platform supports it. Prioritize multi-tenant nodes, internet-adjacent hosts, and CI runners that execute untrusted code.
3. Rebuild container images. Containers inherit the host kernel, but base images and node images still need refreshing where they pin kernel-coupled components; rebuild and redeploy so nothing ships on an old node image.
4. Apply interim mitigations if you must wait. Where an immediate reboot is impossible, reduce exposure: disable kTLS if unused, remove ARP-rewriting ebtables SNAT rules, restrict the CAP_NET_ADMIN capability, and block the af_alg module after assessing impact. These are stopgaps, not fixes.
5. Hunt, then test. Follow CISA's triage requirement — review logs on exposed hosts for signs of prior exploitation, not just for the patch state — and add kernel and privilege-escalation paths to the scope of your next penetration test so escalation from a foothold is something you probe deliberately.

Frequently asked questions

Sources

The Hacker News — CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild
CISA — Known Exploited Vulnerabilities Catalog
Cyber Security News — CISA Warns of Linux Kernel Vulnerabilities Actively Exploited in Attacks