Three Linux Kernel vulnerabilities have been added to the CISA Known Exploited Vulnerabilities, or KEV, catalogue following evidence of active exploitation. The vulnerabilities are CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964. Their inclusion in the KEV catalogue changes the way organisations should approach them. These are no longer vulnerabilities that can be assessed solely on the basis of their CVSS scores or theoretical exploitability. They now require operational prioritisation.

The three vulnerabilities affect different components of the Linux kernel. CVE-2025-39682 affects the kernel TLS receive path and can result in memory disclosure or system instability when unusual TLS conditions are processed. CVE-2026-53266 affects the ebtables SNAT and ARP rewrite path and involves an out-of-bounds write condition that may lead to a system crash or, depending on the affected environment and exploitation conditions, privilege escalation. CVE-2025-39964 is associated with a race condition involving concurrent AF_ALG socket writes, which can lead to data corruption or a system crash.

The most important point is not simply that these vulnerabilities exist. Their addition to the CISA KEV catalogue indicates that evidence of exploitation has been identified in real-world environments. This distinction matters because a vulnerability with a high CVSS score is not automatically being exploited, while a vulnerability with a comparatively lower severity score may become significantly more important once active exploitation is confirmed.

For security teams, this reinforces an important principle in modern vulnerability management: severity and actual risk are not the same thing.

A CVSS score provides a standardised view of technical severity. It helps organisations understand factors such as attack complexity, privileges required, user interaction, and potential impact on confidentiality, integrity, and availability. However, CVSS alone does not show whether attackers are currently using the vulnerability, whether the affected system is exposed, whether the vulnerable functionality is enabled, or how critical the affected asset is to the organisation.

For this reason, vulnerability prioritisation should combine several factors, including asset criticality, exposure, exploitability, active exploitation status, vendor guidance, and the operational importance of the affected system.

The presence of all three vulnerabilities in the same KEV update should also be interpreted carefully. Their simultaneous inclusion does not prove that they are being chained together in a single attack. It does not establish that one threat actor is responsible for exploiting all three vulnerabilities, nor does it confirm that the same exploitation technique is being used across all observed cases.

At present, the key fact is that active exploitation has been confirmed. The exact exploitation mechanisms, attacker attribution, victim profiles, and possible relationships between the three vulnerabilities remain less clear. The advisory therefore makes an important distinction between what is confirmed and what is still unknown.

This distinction is particularly important for threat intelligence, incident response, and vulnerability management teams. When exploitation details are incomplete, organisations should avoid making assumptions based on incomplete public reporting. Instead, remediation decisions should be based on verified exposure within their own infrastructure.

The first step should be to establish an accurate inventory of Linux systems. This includes traditional servers, virtual machines, container hosts, appliances, and embedded systems. Teams should identify the exact Linux distribution, kernel version, package version, and relevant configuration for each system.

Simply determining that a system runs Linux is not enough. Linux distributions often backport security fixes into existing package branches without changing the version number in the same way as upstream kernel releases. As a result, organisations should not rely exclusively on upstream version comparisons when determining whether a system is vulnerable.

The correct approach is to compare each affected system against the security advisory published by the relevant Linux distribution or vendor.

Configuration also matters.

CVE-2025-39682 relates to the kernel TLS receive path, which means organisations should determine whether the relevant kTLS functionality is actually enabled and used within their environment.

CVE-2026-53266 relates to the ebtables SNAT and ARP rewrite path. Systems using bridge networking, ebtables, or related SNAT configurations therefore deserve particular attention.

CVE-2025-39964 affects the AF_ALG interface, which exposes Linux kernel cryptographic functionality to user space. Security teams should establish whether this functionality is available, actively used, or accessible to users or applications within the affected systems.

This is where exposure-based vulnerability management becomes significantly more valuable than simple CVE scanning.

The relevant question is not merely whether a vulnerability appears in a scanner result. The organisation needs to understand whether the vulnerable component exists on a specific asset, whether the vulnerable functionality is active, whether an attacker can reach or trigger it, and what the business impact would be if the system were compromised.

The remediation process should therefore begin with the identification of affected assets, followed by validation against vendor advisories. Security updates or vendor-recommended mitigations should then be applied according to the organisation's risk and change-management procedures.

However, patching should not be treated as the end of the investigation.

Because these vulnerabilities have been associated with active exploitation, organisations should also review telemetry from affected systems. Kernel crash reports, unusual network behaviour, unexpected process activity, system instability, and events associated with the affected subsystems should be investigated where appropriate.

The absence of publicly available exploitation details does not mean that defenders should wait for a complete technical write-up before taking action. In fact, the opposite is often true. When active exploitation is known but the exact mechanism remains unclear, reducing the exposure window becomes even more important.

The advisory recommends identifying every Linux system in the environment, validating the exact kernel and distribution, consulting vendor-specific advisories for the three CVEs, reviewing relevant logs and crash reports, and continuing to monitor vendor and security advisories as additional technical details become available.

This case also highlights a broader weakness in traditional vulnerability management programmes.

Many organisations still prioritise remediation primarily according to CVSS scores. A vulnerability rated 9.8 may automatically move to the top of the queue, while another vulnerability with a score of 7.8 or lower may remain unresolved for weeks.

That model is increasingly insufficient.

A more mature approach considers CVSS as only one input within a broader risk model. KEV status, internet exposure, exploitability, asset criticality, business context, existing security controls, and available remediation options should all influence prioritisation.

The practical objective should not be to patch every vulnerability at the same speed. The objective should be to identify which vulnerabilities represent the greatest real-world risk to the organisation and to reduce that risk as quickly as possible.

From a CyberDistro perspective, this is where vulnerability and exposure management become operational rather than theoretical.

The challenge is not discovering that another CVE has been published. Security teams already receive thousands of vulnerability notifications every year. The real challenge is answering a much more specific set of questions.

Is the vulnerability present in our environment?

Which assets are affected?

Is the vulnerable functionality actually enabled?

Is the system exposed to a realistic attack path?

Has the vendor released a fix?

Has remediation already been applied?

And because exploitation has been observed, should we investigate whether the vulnerability may already have been abused?

A mature security programme should be able to move from a public vulnerability disclosure to these answers quickly.

The three Linux Kernel vulnerabilities currently listed in CISA KEV provide a useful example of why vulnerability management must move beyond static severity scores. The combination of asset visibility, exposure validation, threat intelligence, vendor context, remediation prioritisation, and continuous monitoring is what turns a CVE notification into an actionable security decision.

Active exploitation has been confirmed. The precise exploitation mechanism remains unclear.

For organisations operating Linux systems in production, the priority is therefore straightforward: identify affected systems, validate exposure against the relevant distribution advisory, apply the required remediation, review available telemetry, and continue monitoring for further technical information.

In vulnerability management, knowing that a vulnerability exists is only the beginning.

The more important question is whether it exists in your environment, whether it can be exploited, and how quickly you can reduce the resulting exposure.