CISA Flags Three Actively Exploited Linux Kernel CVEs: Patch Deadline Already Passed

CISA added three actively exploited Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalog on September 18, 2026, with a federal remediation deadline of just 3 days, September 21, which has already passed as of this writing. If you manage Linux systems and haven’t checked your kernel version against these three CVEs yet, you’re already past the timeline CISA gave federal agencies, worth treating as genuinely urgent rather than routine patching backlog.

The three vulnerabilities

CVE-2025-39682 (CVSS 9.8): an improper check for unusual or exceptional conditions in the Linux kernel’s TLS receive path, specifically in how the kernel handles zero-length records on the receive list. It can allow authenticated local users to trigger memory disclosure or a denial-of-service condition. This is the most severe of the three and the one CISA gave the shortest, strictest deadline for, a 3-day window applying across all assets, not just internet-facing ones.

CVE-2026-53266 (CVSS 8.8): an out-of-bounds write in the ebtables Source Network Address Translation (SNAT) ARP rewrite path, allowing a local attacker to trigger unintended system behavior, a denial-of-service condition, or local privilege escalation.

CVE-2025-39964 (CVSS 7.8): a race condition allowing concurrent writes to the same AF_ALG socket (the kernel’s cryptographic API socket interface), letting a local attacker crash the system or corrupt cryptographic operation results, causing either a DoS condition or data integrity issues in whatever relied on that crypto operation completing correctly.

What CISA’s deadline actually requires

Under Binding Operational Directive 26-04, CVE-2025-39682 carries a 3-day remediation window across all assets, both internal and publicly exposed. The other two carry a 3-day deadline specifically for publicly exposed assets, and a 14-day deadline for internal assets. BOD 26-04 is formally binding only on federal civilian agencies, but CISA’s KEV catalog additions are widely treated as an authoritative signal of real, current exploitation for any organization, the deadline structure itself is a reasonable prioritization guide even if you’re not legally bound by it.

Patch it, there’s no clean workaround

# Check your current running kernel version
uname -r

# Fixed versions:
# CVE-2025-39682: 6.1.149, 6.6.103, 6.12.44, 6.16.4 and later
# CVE-2025-39964: 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9 and later
# CVE-2026-53266: 5.10.259, 6.1.176, 6.12.94 and later
# Confirm the exact fixed version for your specific distribution's kernel
# package against your distro's own advisory, backport version numbers
# can differ from upstream kernel.org version numbers

All three require a kernel update followed by a reboot, there is no configuration-only fix for CVE-2025-39682 that closes the hole without disabling kTLS entirely, which is a significant capability to lose just to avoid a reboot. For CVE-2025-39964, Red Hat’s guidance does document a module-level mitigation, blacklisting af_alg from loading, but this disables all kernel-mediated cryptography for any application depending on it, a workaround with real functional cost, not a free interim fix. Treat these as genuine “schedule the reboot” situations rather than looking for a way to avoid one, the workarounds available cost more in lost functionality than most environments should accept as a substitute for patching.

Why three separate local-privilege/DoS kernel bugs together matter

None of these three are remote, unauthenticated flaws on their own, they require local access or a local authenticated session. But that’s exactly the profile that matters most in a post-initial-compromise scenario: an attacker who’s already gained a foothold through some other means (a compromised application, a phished credential, a misconfigured service) uses exactly this kind of local kernel vulnerability to escalate privileges or maintain persistence. CISA’s KEV additions specifically confirm active exploitation, meaning these aren’t theoretical local-access risks, they’re documented as already being used against real systems.

Frequently asked questions

We only run these systems on an internal network with no direct internet exposure. Do we still need to patch within 3 days?
For CVE-2025-39682 specifically, CISA’s directive applies the 3-day window to all assets regardless of exposure. For the other two, internal assets get a 14-day window under BOD 26-04’s own structure, still worth prioritizing given confirmed active exploitation, just with slightly more runway than internet-facing systems.

Can we mitigate any of these without a reboot in the short term while we schedule proper maintenance?
Only CVE-2025-39964 has a documented interim mitigation (blacklisting the af_alg module), and it comes with a real functional cost, losing kernel-mediated cryptography for anything depending on it. The other two have no clean workaround short of disabling significant functionality (kTLS) or patching. Schedule the reboot rather than relying on a partial mitigation as a long-term substitute.

How do we confirm whether these vulnerabilities have actually been exploited against our specific systems?
Check your kernel version against the fixed versions above first, that tells you whether you’re currently exposed. For evidence of actual prior exploitation, review system logs and any available audit/security monitoring for anomalous local privilege escalation events or unexpected crashes correlated with the affected kernel subsystems (TLS receive path, ebtables SNAT, AF_ALG), though detecting exploitation of kernel-level flaws after the fact is genuinely difficult without dedicated kernel-level auditing already in place.