CVE-2025-39682: Linux Kernel kTLS Receive-Path Flaw Lands on CISA KEV

TL;DR

CVE-2025-39682 is a Linux kernel TLS (kTLS) receive-path flaw (CWE-754) in which a zero-length record pulled from the rx_list bypasses the intended recvmsg() record-type handling, allowing subsequent TLS records to be processed under incorrect zero-copy and queuing assumptions. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-18 with a remediation due date of 2026-09-21, so any Linux host that terminates TLS in-kernel — web front ends, VPN concentrators, service meshes, container hosts — should be treated as actively targeted. Apply the vendor kernel update or disable kTLS and fall back to user-space TLS today.

What is this vulnerability?

Field	Value
CVE	CVE-2025-39682
Vendor / product	Linux / Kernel (kTLS receive path)
Weakness	CWE-754 — Improper Check for Unusual or Exceptional Conditions
CISA KEV added	2026-09-18
CISA remediation due	2026-09-21
Known ransomware use	Unknown
Public exploit / PoC	Yes — GitHub reference (khoatran107/cve-2025-39682)
EPSS	0.012 (percentile ~0.668)
CVSS	7.1 HIGH (NVD, AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H); a separate CVSS 3.1 vector of 9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) has also circulated

Overview

CVE-2025-39682 is a correctness flaw in the Linux kernel's TLS subsystem — the in-kernel TLS implementation commonly referred to as kTLS — that was disclosed on 2025-09-05 and subsequently added to CISA's Known Exploited Vulnerabilities catalog on 2026-09-18. The KEV entry carries a remediation due date of 2026-09-21, an unusually tight three-day window that signals the U.S. federal government and, by extension, the broader defender community should treat this as an actively exploited issue rather than a theoretical one.

The flaw lives in the kTLS receive path, specifically in how the kernel handles zero-length records that have been queued on the rx_list. Because kTLS is a shared kernel component, the blast radius is not limited to a single vendor stack. The affected technologies span the upstream Linux kernel and the many distributions and platforms that embed it, including Bottlerocket, Rocky Linux, Alma Linux, Alibaba Cloud Linux (Aliyun Linux), CBL Mariner, Chainguard, Debian, Ubuntu, Red Hat, openSUSE, Amazon Linux, Oracle Linux, and Photon. Any product that ships a Linux kernel with kTLS enabled — including container hosts, hypervisors, appliances, and managed services — inherits the exposure.

Severity signals diverge in a way that defenders should understand rather than argue about. NVD's published vector is 7.1 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H), implying local access with low privileges. A separate CVSS 3.1 vector of 9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) has circulated, implying remote, unauthenticated reachability. The gap reflects genuine disagreement about whether the flaw is remotely triggerable or requires local access to a kTLS-enabled socket. Wiz rates the issue HIGH with a CVSS base of 7.1. The KEV listing is the strongest signal here: patch first, debate the score later. Anyone running Linux servers that terminate TLS in-kernel should care, and because kTLS is embedded in so many products, inventory coverage matters as much as patch speed.

Technical details

The root cause is a logic gap in the kTLS receive path. Each recvmsg() call is supposed to return either a run of contiguous DATA records (any number of them) or exactly one non-DATA record. When the next record has a different type than the one already being processed, the loop breaks out of the main processing path. If that record has already been decrypted — which is common in TLS 1.3, where the record type is not known until after decryption — the pending record is queued onto the rx_list so the next recvmsg() call can pick it up.

Queuing an skb to rx_list after a zero-copy decrypt is not possible, because in that case the kernel decrypted directly into the user-space buffer and there is no skb to queue; darg.skb still points at the ciphertext skb for metadata such as length. The developers reasoned that only DATA records are eligible for zero-copy, and that the loop breaks after every non-DATA record, so a zero-copy record could never turn out to be a different type. The corner case that was missed is an initial record that arrives from rx_list and has zero length. That zero-length record bypasses the intended record-type handling, and subsequent TLS records can then be processed using incorrect zero-copy and queuing assumptions.

Key technical points for defenders:

• Vulnerable component: the Linux kernel TLS (kTLS) receive path, reachable through the setsockopt() kTLS interface and the normal socket receive path.
• Weakness class: CWE-754, improper check for unusual or exceptional conditions — here, a zero-length record that is not handled as an exceptional condition.
• Attack prerequisites: depend on how the socket is exposed. A local process with access to a kTLS-enabled socket, or a remote peer able to influence TLS record framing on a connection terminated in-kernel, can both be relevant depending on configuration.
• Network exposure: any service that terminates TLS in-kernel and is reachable from untrusted networks, plus any host where an unprivileged local process can open a kTLS socket.
• Auth requirements: the NVD vector assumes low privileges (PR:L); the higher circulated vector assumes none (PR:N). Treat both as plausible until your own exposure is confirmed.
• Trust boundary crossed: the kernel's assumption that record metadata and plaintext placement stay consistent across recvmsg() calls.

Version ranges are distribution-specific. The authoritative fix references are the stable backport commits listed in the resources section below; compare your running kernel against those branches rather than relying on a single upstream version string.

Impact

Successful exploitation can corrupt the kernel's view of record boundaries and types, which may cause plaintext from one record to be delivered in a context intended for another. That creates a realistic confidentiality impact: data that should have been consumed by one logical stream can leak into another read path, or be returned to the wrong caller. Integrity is also at risk because callers may act on mislabeled data, and availability can suffer if the kernel mishandles buffers, leading to crashes, hangs, or socket resets.

Because kTLS is used by high-throughput services, a single affected host can process a very large number of connections, so even a low-probability trigger can matter at scale. Realistic abuse scenarios include cross-connection data disclosure, protocol confusion in proxies that trust kernel TLS framing, and denial of service against TLS-terminating endpoints. In multi-tenant environments, the shared kernel means one tenant's traffic can influence the receive path used by another.

For defenders, the business exposure is concentrated in three places: internet-facing TLS terminators, multi-tenant container hosts and hypervisors, and any environment where a local unprivileged process can reach a kTLS socket. The KEV listing and the short three-day remediation window indicate that exploitation is not theoretical, and the presence of a public proof-of-concept repository lowers the barrier to experimentation. The impacted product set may include end-of-life or end-of-service kernels; where that is the case, migration to a supported version is the correct remediation rather than relying on backports that will never arrive.

Exploitability

CVE-2025-39682 is listed in CISA's Known Exploited Vulnerabilities catalog (added 2026-09-18, due 2026-09-21), which is the clearest available signal that exploitation has been observed in the wild. CISA does not report known ransomware use for this CVE at the time of listing.

The EPSS score is modest at 0.012, with a percentile of roughly 0.668 — meaning the model estimates a low probability of exploitation in the next 30 days relative to other CVEs. That low EPSS number should not be read as reassurance. EPSS is a probabilistic model that does not account for targeted exploitation, and it frequently lags behind KEV additions for kernel and embedded-component flaws. The KEV entry overrides the EPSS signal for prioritization purposes.

A public proof-of-concept repository exists on GitHub (khoatran107/cve-2025-39682), which raises concern among defenders that the barrier to experimentation is low. Kernel developers framed the fix as a narrow correctness fix in the TLS receive path rather than a broad architectural problem, and stable backports were merged across multiple branches. The practical takeaway is that defenders should not wait for a definitive score: the KEV entry and the existence of public code are sufficient reason to patch.

KEV vs CVSS vs EPSS

Signal	What it measures	Action for this CVE
CISA KEV	Confirmed in-the-wild exploitation; carries a binding remediation due date for U.S. federal agencies and a strong prioritization signal for everyone else	Treat as actively exploited. Patch by 2026-09-21 or apply compensating controls immediately.
CVSS (NVD 7.1 HIGH; circulated 9.8 CRITICAL)	Theoretical severity of the flaw under a stated attack model	Use to size impact, not to sequence work. The vector disagreement (local vs remote) means your own exposure assessment matters more than the number.
EPSS (0.012, ~66.8th percentile)	Modeled probability of exploitation in the next 30 days	Do not use to deprioritize. Low EPSS here is outweighed by KEV status and public PoC availability.

Exploitation steps (defensive triage)

This section is written for defensive triage and validation. It does not provide a weaponized chain.

1. Inventory kTLS usage. Identify hosts running kernels with kTLS enabled and confirm whether the kTLS receive path is in use by any service. Check application and proxy configurations for TLS_RX/TLS_TX socket options, and inspect sockets on running hosts.
2. Determine exposure. For each host, ask two questions: is the TLS endpoint reachable from untrusted networks, and can a local unprivileged user open a kTLS socket on the host? Either answer being "yes" raises priority.
3. Confirm kernel version against fix commits. Compare the running kernel against the stable fix commits listed in the resources section to confirm whether the host is in the vulnerable range. Remember that container and VM guests share the host kernel.
4. Hunt host telemetry. Correlate for unusual recvmsg() behavior, zero-length record handling, or socket errors around the time of suspected activity. Look for TLS subsystem warnings or oopses in dmesg/journal output.
5. Check for post-exploitation activity. Look for unexpected outbound connections, new listeners, privilege changes, or data flows that do not match the host's normal role.
6. Preserve before rebooting. If exploitation is suspected, isolate the host, capture volatile memory and socket state, and preserve logs before rebooting — the vulnerable state is lost on restart.
7. Patch or compensate. Apply the vendor kernel update. If patching is not immediately possible, disable kTLS for the affected service and fall back to user-space TLS.
8. Verify and document. Confirm the running kernel version after reboot, document the timeline and scope, and report per your incident response process and any applicable BOD 26-04 requirements.

Indicators of compromise

• Kernel log messages (dmesg/journal) referencing TLS, skb, rx_list, or zero-length record handling, especially warnings or oopses in the TLS subsystem.
• Unexpected socket errors, resets, or truncated reads on TLS-terminating services that do not correlate with known network issues.
• Application logs showing plaintext or record data delivered to the wrong request context, or protocol parse errors in proxies that trust kernel TLS framing.
• EDR or audit telemetry showing unprivileged processes calling setsockopt() with SOL_TLS options, or unusual access to kTLS-enabled sockets.
• Network flow anomalies: repeated short or zero-length TLS records, unusual record-type sequences, or connections that stall after a zero-length record.
• Sudden CPU spikes or soft lockups on hosts that terminate many TLS connections in-kernel.
• New or unexpected outbound connections from TLS-terminating hosts, which may indicate data exfiltration after a confidentiality break.
• Crashes or reboots of container hosts or hypervisors that run kTLS workloads, particularly where the same kernel image is shared across tenants.

Mitigation and workarounds

The primary fix is to update the Linux kernel to a version that includes the stable commits referenced for this CVE. Because the flaw is in kTLS, the most reliable compensating control is to stop using in-kernel TLS on affected hosts and terminate TLS in user space — in the application, a reverse proxy, or a library — until the kernel is patched.

Where kTLS is required for performance, restrict which processes can open kTLS sockets and reduce the number of untrusted peers that can reach a kTLS-terminated endpoint. For container and virtualization hosts, ensure the host kernel is patched even if guest images are current, since the vulnerable code runs in the shared kernel. If a product embedding the kernel is end-of-life or end-of-service, plan migration to a supported version rather than relying on backports.

Follow vendor guidance and CISA's BOD 26-04 direction, including the forensics triage requirements, and treat the 2026-09-21 due date as a hard prioritization signal. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines. Finally, validate that the patch is actually loaded by checking the running kernel version after reboot, not just the package version — a common failure mode is a patched package that is not the kernel actually booted.

Community reactions

The disclosure drew attention primarily because of the CISA KEV listing and the unusually short remediation window, which pushed the issue onto patch-priority lists even before a public score was widely agreed upon. Security media and community trackers highlighted the disagreement between the high CVSS 3.1 vector (9.8) and NVD's more conservative 7.1 vector, with discussion centering on whether the flaw is remotely triggerable or requires local socket access. A public proof-of-concept repository appeared on GitHub, which raised concern among defenders that the barrier to experimentation is low, even though the EPSS score remains modest at roughly 0.012. Kernel developers framed the fix as a narrow correctness fix in the TLS receive path rather than a broad architectural problem, and the stable backports were merged across multiple branches. The practical takeaway from community discussion is that defenders should not wait for a definitive score: the KEV entry and the existence of public code are sufficient reason to patch.

FAQ

Is CVE-2025-39682 in CISA's KEV catalog? Yes. CISA added it on 2026-09-18 with a remediation due date of 2026-09-21.

What is the remediation due date and what does it mean? The due date is 2026-09-21. For U.S. federal agencies it is a binding deadline under BOD 26-04; for everyone else it is a strong signal to prioritize patching or apply compensating controls within the same window.

Is this vulnerability internet-facing? It depends on your configuration. Any service that terminates TLS in-kernel and is reachable from untrusted networks is exposed. Hosts where an unprivileged local process can open a kTLS socket are also at risk. The CVSS vector disagreement (local vs remote) means you should assess your own exposure rather than assume either answer.

Which products are affected? The upstream Linux kernel and the many distributions and platforms that embed it, including Bottlerocket, Rocky Linux, Alma Linux, Alibaba Cloud Linux, CBL Mariner, Chainguard, Debian, Ubuntu, Red Hat, openSUSE, Amazon Linux, Oracle Linux, and Photon. Because kTLS is a shared kernel component, the affected set spans many products rather than a single vendor stack.

How do I verify the fix is applied? Check the running kernel version after reboot against the stable fix commits listed in the resources section — not just the installed package version. Confirm that the booted kernel matches the patched build, and re-scan hosts with your vulnerability management tooling.

Does a low EPSS score mean I can deprioritize this? No. EPSS is 0.012 here, but KEV status and a public proof-of-concept outweigh the model's estimate. Treat this as actively exploited.

Is there a workaround if I cannot patch immediately? Yes. Disable kTLS for the affected service and terminate TLS in user space until the kernel is patched. Restrict which processes can open kTLS sockets where in-kernel TLS is required for performance.

Related resources

• NVD entry for CVE-2025-39682: https://nvd.nist.gov/vuln/detail/CVE-2025-39682
• Linux stable fix commit 2902c3ebcca52ca845c03182000e8d71d3a5196f: https://git.kernel.org/stable/c/2902c3ebcca52ca845c03182000e8d71d3a5196f
• Linux stable fix commit c09dd3773b5950e9cfb6c9b9a5f6e36d06c62677: https://git.kernel.org/stable/c/c09dd3773b5950e9cfb6c9b9a5f6e36d06c62677
• Linux stable fix commit 3439c15ae91a517cf3c650ea15a8987699416ad9: https://git.kernel.org/stable/c/3439c15ae91a517cf3c650ea15a8987699416ad9
• Linux stable fix commit 29c0ce3c8cdb6dc5d61139c937f34cb888a6f42e: https://git.kernel.org/stable/c/29c0ce3c8cdb6dc5d61139c937f34cb888a6f42e
• Linux stable fix commit 62708b9452f8eb77513115b17c4f8d1a22ebf843: https://git.kernel.org/stable/c/62708b9452f8eb77513115b17c4f8d1a22ebf843
• CISA BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
• CISA BOD 26-04 implementation guidance (forensics triage): https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
• Public PoC reference (GitHub): https://github.com/khoatran107/cve-2025-39682
• Wiz vulnerability database entry: https://www.wiz.io/vulnerability-database/cve/cve-2025-39682