CISA Puts Three Linux Kernel Flaws on KEV, Federal Agencies Get Two Days to Patch

CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog on Friday, September 19, 2026, and gave federal civilian agencies until September 21 to fix them. That is a two day window, and it is the shortest signal CISA has available. Red Hat updated the advisories for all three flaws the same day at 2:00 a.m. UTC to acknowledge active exploitation, with the line: "This CVE is high risk and there are known public exploits leveraging this vulnerability. Address this vulnerability with high priority."

The three CVEs

Three different subsystems, three different bug classes, one shared precondition: the attacker already has local access.

• CVE-2025-39682 (CVSS 9.8), improper check for unusual or exceptional conditions in the TLS receive path. A local authenticated user can trigger memory disclosure or denial of service. The kernel TLS path handles data after the handshake, so memory disclosure here means leaked kernel memory adjacent to session data.
• CVE-2026-53266 (CVSS 8.8), out of bounds write in the ebtables Source Network Address Translation ARP rewrite path. A local attacker can trigger unintended system behavior, denial of service, or local privilege escalation. This is the one to prioritize: a controlled out of bounds write in a netfilter path is the classic route to root.
• CVE-2025-39964 (CVSS 7.8), a race condition allowing concurrent writes to the same AF_ALG socket. A local attacker can crash the system or corrupt the results of cryptographic operations, producing denial of service or data integrity failures.

The 9.8 on CVE-2025-39682 deserves a note. That score sits in the range most teams reserve for unauthenticated remote code execution, but the described impact is memory disclosure and denial of service from a local authenticated user. Score the ebtables out of bounds write above it in your own triage. An 8.8 that ends in root on the box is worth more attention than a 9.8 that ends in a leak, and CVSS will not make that call for you.

What we know about exploitation, and what we do not

There are currently no public details on how the three vulnerabilities are being exploited in the wild. No threat actor attribution, no campaign name, no indicators of compromise, no confirmation that the three are being used together as a single chain. CISA cited evidence of active exploitation and Red Hat confirmed public exploit code exists, and that is the full extent of the record right now.

That gap matters for how you respond. You cannot hunt for an IOC list that does not exist. You can patch, and you can hunt for the behavior each bug class produces, which is covered in the detection guidance at the end of this post. Treat any writeup that gives you a confident attacker profile for these three CVEs today as speculation.

Local does not mean low

Every one of these requires local access, and that reliably causes teams to downgrade them. The reasoning is that if an attacker already has a shell, the game is over. It is not. The gap between an unprivileged web application user and root is the gap between a contained incident and a rebuilt host, and it is the gap between one container and the node underneath it.

Multi-tenant infrastructure is where this hurts most. Shared hosting, CI runners that execute untrusted pull request code, Kubernetes nodes running workloads from multiple teams, and any VDI or jump host with interactive user sessions all hand an attacker the local access precondition by design. A kernel privilege escalation on a CI runner means the build secrets for every project on that runner. On a container host, it means every other tenant on the node.

CVE-2025-39964 has a second order effect worth naming. Corrupting the results of cryptographic operations is not just a crash. AF_ALG exposes the kernel crypto API to userspace, and applications that route hashing or encryption through it can be pushed into producing wrong output without failing loudly. Integrity checks that silently return the wrong answer are worse than integrity checks that error.

Four more kernel LPE bugs landed the same week

Separately from the KEV additions, researcher Asim Manizada disclosed four local privilege escalation flaws in the Linux kernel: CVE-2026-80844 (DirtyAH6), CVE-2026-81000 (TUNderflow), CVE-2026-68121 (PPPoEject), and CVE-2026-74469 (DiagSpill). These are not on the KEV catalog and are not confirmed as exploited in the wild. They do bring the week's total to seven kernel local privilege escalation issues with public detail attached, which changes the arithmetic on kernel patch cadence. If your fleet reboots for kernel updates on a quarterly schedule, this week is the argument for changing that.

What to do now

• Inventory kernel versions across the fleet first. You cannot prioritize what you have not counted, and the answer is usually worse than the CMDB says.
• Patch and reboot multi-tenant hosts first: CI runners, container nodes, shared hosting, jump boxes, VDI. Single tenant application servers where nobody has a shell are a lower tier.
• Match the fixed build from your distribution's advisory, not from a CVE database. The source material does not name an upstream fix version, and Red Hat, Ubuntu, SUSE, and Debian each ship their own backported build numbers.
• Remember that a kernel package install does nothing until reboot. Check your running kernel after the maintenance window, not your installed package list.
• If a reboot has to wait, reduce reachable attack surface: block the AF_ALG modules where nothing legitimately uses them, and confirm whether ebtables is actually needed on that host.

Fast triage

uname -srvm
lsmod | grep -E 'algif|^tls|ebtable'
journalctl -k --since "7 days ago" | grep -icE 'general protection fault|BUG: |Oops'

The last command counts kernel oops and general protection fault entries from the past week. Exploitation attempts against memory corruption bugs like CVE-2026-53266 frequently fail before they succeed, and a host with a nonzero count that used to sit at zero is worth a closer look before you reboot it and lose the ring buffer.