Three Exploited Linux Kernel Flaws, a Three-Day Deadline: How to Triage Your Fleet

Patch the kernel and reboot, starting with internet-facing systems that use kernel TLS. On September 18, 2026, CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog, CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964, and required federal agencies to remediate by September 21 under Binding Operational Directive 26-04 (Cyber Security News). A kernel package update that has not been followed by a reboot has not fixed anything.

Kernel KEV entries are awkward for most operations teams. They touch every Linux host, the fix requires a restart, and exploitability depends heavily on configuration. The way through is to sort hosts by exposure before you start scheduling reboots.

The three bugs

• CVE-2025-39682, kernel TLS receive path. An improper condition check involving zero-length TLS records can lead to memory disclosure or denial of service on systems with kTLS enabled on TCP sockets. Network traffic can reach the affected code. It is the most serious of the three.
• CVE-2026-53266, netfilter bridge ebtables SNAT. An out-of-bounds write when the ebtables SNAT target rewrites ARP sender hardware addresses (NVD). It requires a specific bridge netfilter configuration, and Red Hat describes it as allowing a local attacker on a system so configured to corrupt memory (Red Hat).
• CVE-2025-39964, AF_ALG crypto sockets. A race condition where concurrent writes to the same socket can corrupt internal cryptographic state, causing crashes or incorrect results. It is a local, low-privilege issue.

CISA did not disclose who is exploiting these flaws or how. KEV listing means CISA has evidence of exploitation in the wild, not that every configuration is equally exposed (Cyber Security News).

Why the deadline is three days

BOD 26-04, issued in June 2026, replaced one-size-fits-all KEV deadlines with risk-tiered timelines that can be as short as three calendar days. Exposure, KEV status, and the availability of automated exploitation drive the tier, and the directive expects forensic triage for signs of compromise, not just confirmation that a patch was applied (CISA KEV catalog). Private organizations are not bound by it, but three days for exposed systems is a defensible internal target.

Triage order

1. Internet-facing hosts using kTLS. Check whether the tls kernel module is loaded (lsmod | grep tls) and whether your web servers, proxies, or storage software enable kernel TLS offload. These go first.
2. Hosts with ebtables or bridge netfilter rules, typically hypervisors, container hosts, and virtual networking appliances. Look for SNAT rules that rewrite ARP sender addresses.
3. Multi-tenant and shared systems where untrusted local users or workloads exist, since the AF_ALG and ebtables bugs need local access.
4. Everything else on your normal accelerated patch cycle.

Temporary mitigations

If a reboot window is days away, reduce exposure in the meantime: disable kTLS where nothing needs it, remove unneeded ebtables SNAT rules that rewrite ARP sender hardware addresses, and block the af_alg module from loading if no application uses it. These are stopgaps, not substitutes. Red Hat's CVE pages list the errata for each supported release (Red Hat); check your distribution's equivalent.

Verify the running kernel, not the installed one

The most common failure we see with kernel advisories is a fleet that shows "patched" in the package manager while still running the old kernel. Compare uname -r against the fixed version on every host, and make your patch management reporting key on the running kernel. Live-patching services can help on systems that genuinely cannot reboot, but confirm the specific CVEs are covered.

Containers do not dodge this

Containers share the host kernel. A patched base image does nothing for a kernel bug; the node must be updated. If you run managed Kubernetes, check your provider's node image release notes. We covered the same shared-kernel lesson in our post on an earlier Linux KEV entry and container risk.

Cyberuptive's vulnerability management team tracks running-kernel versions across client fleets so KEV entries like these become a report, not a scramble. Reach out if you want that view of your environment.

Frequently asked questions

Which Linux kernel vulnerabilities did CISA add to KEV on September 18, 2026?

CVE-2025-39682 in the kernel TLS receive path, CVE-2026-53266 in the netfilter bridge ebtables SNAT target, and CVE-2025-39964 in the AF_ALG cryptographic socket interface.

What was the federal deadline for these Linux kernel KEV entries?

CISA required Federal Civilian Executive Branch agencies to remediate by September 21, 2026, roughly three days after listing, under Binding Operational Directive 26-04.

Are all Linux systems equally exposed?

No. CVE-2025-39682 matters most on systems using kernel TLS, CVE-2026-53266 requires specific ebtables SNAT rules, and CVE-2025-39964 requires local access. Prioritize internet-facing kTLS hosts, then hypervisors and container hosts.

Do I need to reboot after updating the kernel?

Yes. Installing a kernel package does not change the running kernel. Verify with uname -r that each host is running the fixed version, or confirm a live patch covers the specific CVEs.

Does updating container images fix Linux kernel vulnerabilities?

No. Containers share the host's kernel, so the host or node must be updated and rebooted.