CVE-2025-39682 is now in the CISA Known Exploited Vulnerabilities catalog after CISA said there is evidence of active exploitation. The flaw affects the Linux kernel TLS receive path, commonly referred to as kTLS, and Linux administrators should now treat version and package verification as an urgent remediation task rather than a routine CVE review.
Direct answer: identify the running Linux kernel and distribution, check the distribution vendor’s CVE-2025-39682 package status, install the vendor-supported fixed kernel and verify that the fixed kernel is actually running. Do not assume that every Linux 6.x host is exposed, that a generic upstream kernel number proves remediation for every distribution, or that CISA’s exploitation confirmation proves a universal remote-code-execution outcome.
What changed with CVE-2025-39682?
The vulnerability itself was disclosed before the current alert, but the information state changed when CISA added CVE-2025-39682 to its Known Exploited Vulnerabilities catalog on September 18, 2026. That means CISA has evidence that the vulnerability has been exploited in the wild.
This is materially different from a normal vulnerability disclosure. Administrators now have a confirmed exploitation signal and should prioritize exposure and remediation checks accordingly.
What is CVE-2025-39682?
The reviewed Linux kernel vulnerability records describe a flaw in the kernel TLS receive path. The issue involves handling of a zero-length TLS record in the affected code path and can result in unsafe kernel memory handling.
Upstream records trace the vulnerable code to Linux 6.0-era changes, but that does not mean every system reporting a Linux 6.x kernel is necessarily vulnerable in the same way. Distribution maintainers may backport patches, carry different package revisions or expose the affected functionality differently.
Which upstream Linux versions contain the fix?
The reviewed Linux/CVE records identify fixed upstream branch points including 6.1.149, 6.6.103, 6.12.44 and 6.16.4, with later upstream development containing the fix as well.
These upstream versions are useful reference points, but they should not be treated as a universal distribution package matrix. Ubuntu, Debian, SUSE, Amazon Linux, Red Hat and other distributions can backport the patch into a kernel package whose version string does not match the upstream fixed branch exactly.
How to check whether your Linux system is affected
1. Identify the running kernel
Record the kernel that is actually running on the system, not only the newest package installed on disk.
2. Confirm the Linux distribution and release
The applicable fixed package depends on the vendor, release and support branch.
3. Check the vendor’s CVE record
Use the current security tracker or advisory for that exact distribution and release to determine whether the installed package is affected, fixed or not applicable.
4. Install the vendor-supported fixed kernel
Use the supported security update path for the operating system rather than substituting a generic upstream kernel number unless that is how the environment is maintained.
5. Activate the fixed kernel
A newly installed kernel may require a reboot or another environment-specific activation step before the vulnerable kernel is no longer running.
6. Verify the running state
After remediation, confirm that the active kernel corresponds to the vendor-supported fixed package and record the result for vulnerability-management or incident-response evidence.
Why distro package status matters more than a generic version number
Linux distributions routinely backport security fixes. A package can contain the relevant patch without sharing the same version string as the upstream branch where the fix first appeared. Conversely, simply seeing a numerically newer-looking kernel string without checking the distribution’s advisory is not a reliable way to prove remediation.
For CVE-2025-39682, TPS therefore recommends using upstream fixed branches to understand the patch history while using the applicable vendor security tracker to make the final host-level remediation decision.
Is this the same vulnerability as CVE-2025-39964?
No. CVE-2025-39682 is a Linux kernel TLS receive-path issue. TPS’s existing CVE-2025-39964 Linux kernel KEV article covers a different vulnerability involving an AF_ALG cryptographic-socket race condition. They are separate CVEs, separate kernel mechanisms and separate remediation records.
Is CVE-2025-39682 definitely a CVSS 9.8 remote vulnerability?
The reviewed authorities do not present one uniform severity/vector assessment. Linux CNA material carries a high network-based assessment, while other reviewed vendor and vulnerability records use different severity or vector interpretations.
That conflict matters. TPS does not treat one CVSS score or vector as universally applicable across every Linux distribution and deployment. Administrators should use the current assessment from the kernel and distribution sources relevant to their environment.
Does CISA’s KEV listing confirm remote code execution?
CISA’s KEV action confirms evidence of exploitation. The reviewed CISA material does not, by itself, establish that every observed exploit produces arbitrary code execution, that every affected host is remotely exploitable from the internet, or that every Linux installation exposes the same vulnerable path.
TPS therefore separates three facts: the Linux flaw exists, CISA confirms known exploitation, and the exact practical impact depends on the affected kernel path, system configuration, distribution package and exploit conditions. Public attack-chain detail remains limited.
What should administrators do now?
Prioritize systems running potentially affected kernels, especially infrastructure where kernel TLS functionality or exposed network services make the vulnerable code path relevant. Check the current vendor advisory for the exact distribution and release, apply the supported fixed kernel and verify the running kernel afterward.
Organizations subject to CISA’s binding remediation requirements should also follow the current KEV due-date and federal guidance applicable to their environment. Other organizations can use KEV inclusion as a strong prioritization signal even when the federal deadline itself does not apply to them.
What remains unknown?
The reviewed evidence does not establish the identity of the threat actor, a complete public exploit chain, the number of successful compromises, a reliable universal IOC set or confirmed ransomware linkage. Those points should not be inferred from KEV inclusion alone.
What happens next?
The most important follow-up signals are distribution-specific package revisions, any CISA KEV note change, public exploit or proof-of-concept disclosure, authoritative indicators of compromise and credible campaign or threat-actor attribution.
Those later developments should update this same CVE-2025-39682 canonical rather than create another page unless the reader job materially changes.
Verification note
TPS reviewed the CISA KEV state, Linux kernel vulnerability records and current distribution security trackers to reconcile exploitation status, upstream fixed branches and distro-specific remediation. The active-exploitation state is confirmed; exact real-world exploit capability, successful compromise count and universal severity/vector characterization remain unresolved.