On September 18, 2026, the Cybersecurity and Infrastructure Security Agency added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog. That single sentence carries more weight than it might first appear to. The KEV catalog is not a list of theoretical risks or things that could someday be exploited; it is a list of flaws that CISA has confirmed are already being used in real attacks. When three kernel-level bugs land on that list at once, and the operating system in question runs the majority of the world's servers, cloud instances, and containers, it is worth pausing to understand what happened and what your organization should do about it.
This is not a single vulnerability with a catchy nickname. It is three separate, unrelated flaws in three different parts of the Linux kernel, tied together only by the fact that all three are now confirmed to be under active exploitation and all three carry the same short deadline.
What CISA actually did
CISA added three CVEs to the KEV catalog: CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964. Under Binding Operational Directive 26-04, which governs how federal civilian agencies prioritize security updates based on risk, covered agencies are required to remediate all three by September 21, 2026, a window of just three days from the catalog addition.
There is a detail here that is easy to miss but matters a great deal: CISA also flagged all three vulnerabilities as requiring forensic triage. That is a distinct instruction from "apply the patch." It means agencies are expected to actively investigate whether systems were already compromised before the fix went in, not simply assume that installing an update closes the book. For any organization, government or private sector, that same posture is the right one to adopt. Patching stops future exploitation; it says nothing about what may have already happened on a system that was vulnerable and exposed.
CISA has not disclosed who is behind the exploitation, which organizations have been targeted, or whether the three flaws are being chained together as part of a single attack campaign. That absence of detail does not reduce the urgency. KEV inclusion by itself confirms that real-world exploitation has occurred; the lack of a public narrative around it simply means defenders are working with less visibility than they would like.
Red Hat updated its advisories for all three vulnerabilities on September 19, 2026, to formally acknowledge active exploitation, stating plainly that each carries known public exploits and should be addressed with high priority.
The three vulnerabilities
CVE-2025-39682: a zero-length record slips through kernel TLS
The most severe of the three, with a CVSS score of 9.8 as assigned by the CVE record, CVE-2025-39682 is a logic flaw in the receive path of kernel TLS, commonly referred to as kTLS. kTLS allows TLS encryption and decryption to be handled directly by the kernel rather than in user space, which is a performance optimization used by some high-throughput services.
The bug lives in how the kernel's recvmsg() function processes records pulled from what is called the rx_list, an internal queue used when TLS 1.3 records need to be re-examined after decryption because their type was not known in advance. Normally, a single recvmsg() call is only supposed to process one of two things: a contiguous run of data records, or exactly one non-data record. If the queued record on the rx_list happens to be zero-length, the code responsible for enforcing that rule can skip a check it should not skip, allowing a mixed sequence of record types to pass through in a way the design never intended. That mismatch produces unsafe socket-buffer handling.
This flaw is only reachable on systems where kTLS is actively enabled and attached to TCP sockets, so it is not a universal Linux exposure the way some kernel bugs are. Where it is enabled, Red Hat notes the vulnerable code path can be triggered remotely, which is what pushes the severity so high for the services that rely on it. It is worth noting that different vendors score this bug differently: NVD's independent analysis rates it lower, describing a local rather than a network attack vector, while the CVE record itself, and Red Hat's own advisory language, treat the network-reachable case as the one that matters for organizations using kTLS. That kind of scoring disagreement is common and is not a reason to relax; it is a reason to understand your own configuration rather than rely on a single number.
CVE-2026-53266: an out-of-bounds write in a bridge firewall feature
CVE-2026-53266 carries a CVSS score of 8.8 and lives in the netfilter bridge subsystem, specifically in the ebtables SNAT (Source Network Address Translation) target. Ebtables is used to filter and rewrite traffic at the Ethernet bridge layer, and one of its optional features allows a rule to rewrite the sender hardware address in ARP packets as they pass through.
The flaw is a classic missing writability check. The kernel code first reads the ARP header safely, then calls a lower-level function, skb_store_bits(), to write the replacement hardware address, but it never confirms that the memory it is about to write into is actually writable. Under specific conditions, that memory can be part of a fragmented socket buffer backed by a file page brought in through a splice operation, meaning the kernel ends up writing directly into memory it should not be touching. The result is memory corruption that can produce unintended behavior, a system crash, or, in a worse case, a path to privilege escalation.
This flaw requires a fairly specific configuration to be reachable: a system that has bridge netfilter rules configured with the ARP-rewriting SNAT option in use. Red Hat's advisory frames the realistic threat model as a local attacker who is already positioned to interact with a system running that configuration, rather than an anonymous internet-wide attack surface. That narrower reachability is exactly why organizations should not assume this one applies broadly without checking their own bridge and netfilter configuration first.
CVE-2025-39964: a race condition in the kernel's cryptography interface
The third flaw, CVSS 7.8, sits in AF_ALG, the kernel's socket-based interface for cryptographic operations. AF_ALG lets user-space applications hand off encryption, hashing, and similar operations to kernel-level cryptographic implementations through a socket, rather than performing them entirely in user space.
The bug is a race condition: the kernel did not enforce exclusive write ownership on an AF_ALG socket, meaning two writers could issue sendmsg() calls against the same socket at the same time. When that happens, data from the two writers can interleave unpredictably, and the socket's internal state can end up inconsistent with what either writer expected. A local, low-privileged user exploiting this can crash the system or corrupt the results of a cryptographic operation in progress, producing either a denial-of-service condition or, depending on what that cryptographic operation was protecting, a data integrity problem. The fix introduces a write-ownership flag so that only one writer can hold the socket for a sendmsg() call at a time.
Who is affected, and where the risk actually concentrates
All three of these are Linux kernel vulnerabilities, which on paper means an enormous installed base: cloud instances, container hosts, on-premises servers, network appliances built on Linux, and much more. But "affects the Linux kernel" and "every Linux system is equally exposed" are not the same statement, and it is worth being precise about the difference.
CVE-2025-39682 matters most for systems that have kernel TLS enabled and attached to TCP sockets, a feature used by specific high-performance networking and storage stacks rather than every general-purpose server. CVE-2026-53266 matters most for systems running bridge networking with ebtables SNAT rules that use the ARP hardware-address rewrite option, a fairly specialized networking configuration often found in virtualization hosts, container networking layers, and custom bridge setups. CVE-2025-39964 is the broadest of the three in terms of reachability, since any system exposing AF_ALG to local users is potentially affected, but it also requires local access to exploit rather than being reachable directly from the internet.
Where these risks concentrate in practice:
Cloud and virtualization hosts. Hypervisors and cloud platform nodes frequently make heavy use of bridge networking and may enable kTLS for performance reasons, putting them squarely in the exposure window for two of the three flaws.
Multi-tenant and container environments. Any environment where multiple tenants or workloads share a kernel is a place where a local privilege escalation or a crypto-socket race condition carries outsized consequences, since a single compromised or malicious tenant can affect the whole host.
Systems already carrying some level of local access. CVE-2025-39964 and, in its local-access framing, CVE-2026-53266 both assume an attacker already has some foothold, whether through a compromised account, a vulnerable application providing shell access, or an insider. Organizations that have other unpatched vulnerabilities providing that initial foothold should treat these kernel bugs as the next stage of a potential attack chain, not an isolated concern.
Federal systems and their contractors. The BOD 26-04 deadline applies directly to federal civilian agencies, but the same three-day remediation window is a reasonable benchmark for any organization handling sensitive data or operating critical infrastructure, whether or not the directive technically applies to them.
It is also worth placing this KEV addition in a broader context. The same week, a security researcher published proof-of-concept exploits for four additional Linux kernel local privilege escalation flaws unrelated to this trio. Combined with a string of Linux kernel privilege escalation disclosures earlier this year, this has been a difficult stretch for teams responsible for kernel patch management, and it argues for treating kernel update cadence as an ongoing operational priority rather than a once-a-quarter task.
What should you do?
1. Determine which of the three configurations apply to you
Because none of these three bugs affects every Linux system in the same way, the first step is establishing your actual exposure rather than patching blind.
To check whether kernel TLS is in use:
lsmod | grep tls
ss -tan state established | wc -l # combine with application-level checks for SOL_TLS usage
To check for bridge netfilter ebtables SNAT rules with ARP rewriting:
ebtables -t nat -L | grep -i snat
To check whether AF_ALG is loaded and in use:
lsmod | grep af_alg
2. Patch your kernel
All three vulnerabilities have upstream fixes, and major distributions have shipped corrected kernel packages. Apply updates through your normal distribution channel:
# Ubuntu / Debian
sudo apt-get update && sudo apt-get upgrade
# RHEL / Rocky / AlmaLinux
sudo dnf update kernel
# Amazon Linux
sudo dnf update kernel
# SUSE / openSUSE
sudo zypper update kernel-default
# Arch Linux
sudo pacman -Syu
Reboot to load the patched kernel, then confirm the running version:
uname -r
3. If you cannot patch immediately, apply targeted mitigations
Each of the three flaws has a narrower, module-level mitigation available while you work toward a full kernel update. These carry real functional trade-offs, so evaluate them against what your systems actually need before applying them.
For CVE-2025-39682, preventing the tls module from loading removes the vulnerable code path, but it will break any application relying on kernel TLS offload:
echo "install tls /bin/false" | sudo tee /etc/modprobe.d/cve-2025-39682.conf
For CVE-2026-53266, removing or disabling ebtables SNAT rules that use the ARP hardware-address rewrite option closes the specific path, and restricting who can load or modify netfilter rules (via CAP_NET_ADMIN restrictions or a mandatory access control policy such as SELinux or AppArmor) reduces the pool of users who could reach it in the first place.
For CVE-2025-39964, preventing the af_alg module from loading removes the exposure, though this will affect any application that depends on the kernel's crypto socket interface for hardware-accelerated cryptographic operations:
echo "install af_alg /bin/false" | sudo tee /etc/modprobe.d/cve-2025-39964.conf
4. Treat forensic triage as a required step, not an optional one
CISA's own guidance for this KEV addition calls for investigation, not just patching. Before or immediately after applying updates, preserve relevant logs and review exposed systems for kernel crashes, unexpected privilege changes, unusual namespace activity, and unauthorized netfilter rule modifications. If a system was reachable and vulnerable during the exposure window, the absence of obvious evidence of compromise is reassuring but not conclusive, particularly for flaws like these that can leave a thin forensic trail.
5. Review your broader kernel patch cadence
Three actively exploited kernel flaws landing on the KEV catalog at once, arriving in the same window as separate public proof-of-concept releases for four other Linux privilege escalation bugs, is a reasonable prompt to ask whether your kernel update process can move faster than your regular maintenance window allows. Organizations relying solely on scheduled patch cycles should consider whether an expedited path exists for KEV-listed vulnerabilities specifically.
Detection
Because these three flaws sit in different subsystems, useful detection signals differ across them, but a few general patterns apply.
For the kTLS flaw, watch for unexpected crashes or abnormal behavior in services using kernel TLS offload, along with kernel log entries referencing TLS socket handling:
dmesg | grep -i tls
journalctl -k --since "24 hours ago" | grep -i tls
For the ebtables SNAT flaw, monitor for unexpected kernel panics or memory corruption signals on hosts running bridge networking, and audit netfilter rule changes for anything unauthorized:
ebtables -t nat -L -v
journalctl -k --since "24 hours ago" | grep -iE "panic|corrupt|oops"
For the AF_ALG race condition, review application and kernel logs for unexplained cryptographic operation failures or unexpected process crashes tied to processes using the crypto socket interface.
In all three cases, because kernel-level exploitation frequently leaves little on-disk trace, syscall-level monitoring through tools such as auditd or an eBPF-based agent will generally provide more reliable detection than file integrity monitoring alone.
Summary
| CVE-2025-39682 | CVE-2026-53266 | CVE-2025-39964 | |
|---|---|---|---|
| CVSS Score | 9.8 (CVE record) | 8.8 | 7.8 (CVE record) |
| Component | Kernel TLS (kTLS) receive path | Netfilter bridge ebtables SNAT target | AF_ALG cryptographic socket interface |
| Vulnerability type | Improper condition check / record-type confusion | Out-of-bounds write | Race condition |
| Impact | Memory disclosure, denial of service | Memory corruption, DoS, possible privilege escalation | System crash, cryptographic data integrity issues |
| Reachability | Network, when kTLS is enabled and attached to TCP sockets | Local, on systems with vulnerable bridge/ebtables SNAT configuration | Local, low-privilege attacker |
| Added to KEV | September 18, 2026 | September 18, 2026 | September 18, 2026 |
| Federal remediation deadline | September 21, 2026 | September 21, 2026 | September 21, 2026 |
| Interim mitigation | Block the tls module |
Remove/restrict ARP-rewriting ebtables SNAT rules; restrict rule-loading privileges | Block the af_alg module |
| Full fix | Kernel update from your distribution | Kernel update from your distribution | Kernel update from your distribution |
If you need help identifying which of these configurations are present in your environment, applying mitigations without breaking dependent functionality, or carrying out the forensic triage CISA has called for, get in touch. A three-day remediation window across three separate kernel subsystems is not a lot of runway, and getting the exposure assessment right the first time matters more than moving fast in the wrong direction.