Linux Kernel KEV Trio Starts a 72-Hour Clock

Key takeaways on Linux kernel KEV

• Three Linux kernel vulnerabilities added to KEV
• September 21, 2026
• All three entries require forensic triage

What changed and why it matters

The Linux kernel KEV list grew by three vulnerabilities on September 18, and every entry carries the same September 21 remediation date. CISA’s records identify CVE-2025-39682 in the TLS receive path, CVE-2026-53266 in ebtables SNAT processing and CVE-2025-39964 in AF_ALG cryptographic sockets. The operational message is simple: Linux teams need a fleet-level inventory now, because the affected code sits in three different subsystems rather than one easily isolated application.

This is a recovery story tied to the actual public disclosure date, not a fresh reset on September 21. CISA’s KEV feed is the primary record and says all three entries have evidence of exploitation. SecurityWeek, The Hacker News and Tech Times independently reported the same catalog action. They are separate newsrooms; no syndicated copy was counted as a second source.

The flaws do not share one mechanism. CISA describes CVE-2025-39682 as an exceptional-condition handling error in the kernel TLS receive path, where a zero-length record can bypass intended record-type handling. CVE-2026-53266 is an out-of-bounds write in the ebtables SNAT target during an ARP hardware-address rewrite. CVE-2025-39964 is a race condition caused by concurrent writes to one AF_ALG socket, which can interleave data and make the internal state inconsistent.

The operational test

That spread changes the patching question. Administrators should not infer exposure from a single service name or internet scan. They need installed kernel and distribution-package versions, then vendor guidance for each supported branch. CISA’s required action explicitly points operators to vendor mitigations and tells stakeholders to evaluate internet exposure under Binding Operational Directive 26-04.

For covered federal civilian agencies, September 21 is the listed due date. Private companies are not automatically subject to that federal deadline, but the KEV designation remains a useful risk signal because it records observed exploitation rather than theoretical severity alone. Teams should resist turning the three entries into one generic ‘critical Linux bug’: access conditions and likely impact differ, and distribution backports mean an upstream version number may not map cleanly to a vendor package.

The most important extra field is forensicTriage: CISA marks it ‘Yes’ for all three. Patching changes the future state; it does not prove a host was clean before the update. A defensible response therefore preserves relevant telemetry, looks for abnormal privilege use or kernel crashes, and records the evidence used to close the incident. That is the same reason our coverage of how a KEV entry changes GitLab patch priority separates catalog evidence from vendor severity labels.

Maintenance planning matters too. Kernel remediation can require reboot coordination or a verified live-patch path, depending on the distribution. Owners should rank exposed and multi-tenant systems first, confirm that mitigation came from the relevant vendor, and test business services after the change. Our analysis of why containment boundaries still need verification offers the parallel lesson: a boundary is only useful when the organization can prove it held.

The catalog’s three-day interval also puts asset ownership under pressure. A security team can identify a KEV entry centrally, but only the service owner may know whether a host uses a vendor kernel, a cloud image, a container-optimized build or an appliance-managed package. A useful inventory record therefore connects the running system to its distribution, kernel package, support channel, maintenance owner and evidence of the applied fix. Counting devices without that package context can produce a large list that is still impossible to close responsibly.

Containers do not remove the host question. Most containers share the host kernel, so an application image scan alone cannot establish whether one of these kernel paths is present or remediated. Platform teams need to map nodes, managed cluster versions and underlying images to vendor advisories. The public sources cited here do not establish that every Linux deployment is vulnerable; they establish that CISA added three specific vulnerabilities after finding evidence of exploitation. Exposure must still be determined against supported vendor information.

A short deadline creates a temptation to treat reboot success as proof of completion. That is too narrow. After remediation, operators should record the package or build version, confirm that the intended kernel is actually running, and run service checks appropriate to the host. If a supported mitigation is used instead of a patch, the record should name the vendor guidance and the reason for the exception. These are governance controls, not claims about an exploit technique, and they keep later audits from relying on memory.

The forensic requirement deserves a separate workstream. CISA’s feed says forensic triage is required, but it does not publish a victim list, an attacker identity or indicators that would justify attributing a local anomaly to these flaws. Teams should preserve relevant host and security telemetry, review the period before remediation using their established incident procedures, and escalate suspicious evidence rather than inventing a universal indicator set. A clean scan after patching cannot by itself prove that earlier exploitation did not occur.

Leadership reporting should separate four numbers: systems assessed, systems found affected, systems remediated and affected systems with triage completed. Combining them into one patch-compliance percentage hides the difference between reducing exposure and checking for past compromise. It also obscures unsupported or unreachable assets that may need isolation or replacement. Because the public record is narrow, this story does not assign a common severity score, assume a shared attacker or describe an exploit chain across the three bugs.

The concise takeaway is that the Linux kernel KEV trio is an inventory-and-evidence problem as much as a patch problem. Find the affected systems, apply supported fixes or mitigations, perform the required triage and document any exception. CISA has not disclosed exploitation details in the feed, so claims about attackers, victims or a combined exploit chain would go beyond the public evidence and are intentionally excluded here.

Facts table

Frequently asked questions

Which Linux flaws did CISA add?

CVE-2025-39682, CVE-2026-53266 and CVE-2025-39964.

Does the deadline bind private companies?

The listed due date applies to covered federal civilian agencies; private operators can still use KEV as a high-priority signal.

Is installing a patch enough?

CISA's entries also call for forensic triage, so teams should assess whether exploitation preceded remediation.