CISA adds Linux kernel TLS flaw CVE-2025-39682 to KEV catalog

What happened

CISA added CVE-2025-39682, a vulnerability in the Linux kernel’s TLS receive path, to its Known Exploited Vulnerabilities catalog on 18 September 2026, citing evidence of active exploitation [1][2]. The remediation deadline for Federal Civilian Executive Branch agencies was 21 September 2026 — an unusually short window, consistent with the requirements in Binding Operational Directive 26-04 [1][2].

The flaw carries a CVSS score of 9.8 [4]. The published CVE record gives the vector as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Known ransomware use is listed as unknown [1].

There is a discrepancy in the reporting that readers should be aware of. CISA’s own alert describes the addition of a single vulnerability, CVE-2025-39682 [2]. The Hacker News reported the same action as three Linux kernel flaws added to KEV, naming CVE-2025-39682 as the first of them [4]. The other two CVE identifiers are not present in the material available to us, so we are not naming them.

Separately, a researcher has published working exploit code for four Linux kernel bugs that each grant local root; kernel maintainers had already fixed all four upstream over the preceding weeks, and the report is dated 18 September 2026 [3]. The sources do not say when the exploit code itself was released, and they do not state whether CVE-2025-39682 is one of those four. Do not assume the public exploit code applies to this CVE.

Who is affected

Any system running an unpatched Linux kernel that uses kernel TLS (KTLS) on the receive path. None of the provided sources characterise the affected population or how widely KTLS is deployed. Our own reading — not a sourced claim — is that KTLS shows up mainly where TLS record processing is pushed into the kernel for throughput reasons, which makes the exposed set narrower than “all Linux hosts” but not necessarily small.

CISA’s entry adds the standard caveat that affected products may be end-of-life or end-of-service, in which case the advice is to stop using them or move to a supported version [1]. For kernels, this mostly translates to distributions that no longer receive security backports.

The sources do not identify who is exploiting the flaw, against which targets, or how the exploitation was observed. CISA’s KEV entries do not include that detail, and no other provided source supplies it.

How it works

The published CVE record reproduces the upstream fix description, which is specific about the logic error. Each recvmsg() call in the kernel TLS code is supposed to handle either a run of contiguous DATA records or exactly one non-DATA record. When the next record turns out to be a different type than the one already being processed, the loop breaks. Under TLS 1.3 the record type is not known until after decryption, so an already-decrypted record may be parked on the rx_list for the next recvmsg() to collect.

That queuing is incompatible with zero-copy decryption: in the zero-copy path the plaintext has been written straight into the user-space buffer, so there is no socket buffer left to queue. The code’s assumption is that this can never collide — only DATA records are eligible for zero-copy, and processing stops after each non-DATA record.

The missed case, per the same upstream text, is a zero-length record arriving as the first record taken from rx_list. CISA describes the outcome as a zero-length record bypassing the record-type handling in recvmsg(), with later records then handled under “incorrect zero-copy and queuing assumptions” [1].

What that leads to in practice — memory disclosure, corruption, code execution — is not spelled out by the sources. The CVSS vector asserts network attack vector, no required privileges, no user interaction and high impact to confidentiality, integrity and availability, which is consistent with a remotely reachable condition on a KTLS socket, but neither CISA nor the upstream text describes a working attack chain.

What to do

• Patch the kernel. Apply your distribution’s current kernel security update on any host that terminates or consumes TLS via KTLS, and reboot. The bug is fixed upstream.
• Treat the CISA deadline as already passed. The due date was 21 September 2026 [1]. If you are an FCEB agency, or follow KEV as policy, you are in remediation-overdue territory rather than planning territory.
• Check whether you actually use KTLS before deprioritising. grep tls /proc/modules, and check your web server, proxy and NFS configuration for TLS offload settings. Absence of KTLS reduces your exposure; presence on an internet-facing host raises it.
• Follow BOD 26-04’s compromise-check expectation. The directive sets out basic expectations for when agencies must check whether a system was compromised before the patch was applied [2]. That is reasonable practice for anyone: preserve logs and triage internet-exposed KTLS hosts rather than patching and moving on.
• Retire unsupported kernels. If a host runs an EoL kernel with no patch path, CISA’s guidance is to discontinue use [1].
• Patch broadly, not just for this CVE. Public exploit code exists for four separate local-root kernel bugs, all already fixed upstream [3]. Any host behind on kernel updates is exposed to more than one issue.