ATTENTION! Three vulnerabilities in the Linux kernel are actively being exploited in real attacks!
Attention to organizations using the Linux operating system! Experts have learned that three vulnerabilities in the Linux kernel are actively being used in real attacks.
On September 18, 2026, the vulnerabilities CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964 were added to CISA's Known Exploited Vulnerabilities (KEV) catalog. Inclusion in this catalog indicates that these vulnerabilities are being used in real-world attacks.
This is particularly important for government agencies, data centers, cloud infrastructures, servers, network devices, and other information systems running on Linux. This is because the problem is not limited to a simple application bug but relates to the operating system kernel-level mechanisms.
Organizations are required to update vulnerable systems as quickly as possible and also to check whether they have been compromised or not.
Why should these vulnerabilities be given serious attention?
The Linux kernel is one of the most important parts of the operating system, managing interactions with the processor, memory, network interfaces, file system, and other core resources.
Therefore, exploiting a vulnerability in the kernel can lead to:
- system crashes;
- corruption of memory data;
- interruption of service provision;
- escalation of user privileges;
- access to confidential information;
- and in some cases, gaining broader control over the system.
Furthermore, vulnerabilities added to CISA's KEV catalog are not just theoretical issues but are recorded as vulnerabilities actively used in real attacks. Therefore, it is important to remediate them in order of priority based on the risk level, rather than leaving them pending until the next planned technical service.
1. CVE-2025-39682 — Vulnerability in the Linux kernel's TLS mechanism
One of the issues that requires special attention among the three vulnerabilities is CVE-2025-39682.
This vulnerability is related to a logical error that occurs during the data reception process in the kTLS (kernel Transport Layer Security) mechanism in the Linux kernel. The CVE.org data provides a CVSS score of 9.8 for this vulnerability. Red Hat notes that the impact for its products can be assessed by other metrics, as the CVSS score in open-source components may depend on the vendor's configuration and product.
What is the problem?
The kTLS in the Linux kernel processes various TLS records when receiving data. The system must comply with certain rules during a recvmsg() call.
However, in certain special situations, when processing TLS records with a length of zero (rx_list) is taken first, the mechanism for correctly identifying this record type and processing subsequent data may not work as expected.
As a result, the possibility of an incorrect state occurring during the data processing process arises. The problem is particularly relevant for systems where kTLS is enabled and connected to TCP sockets. According to Red Hat data, this code path can be executed remotely, but this requires using the kTLS function.
Therefore, Linux servers that use the internet and are open need to be separately checked.
What should organizations check?
- Whether security updates released by the vendor of the Linux kernel are available;
- Whether the kTLS function is being used or not;
- The configuration of kTLS in services that have internet access;
- System logs and kernel messages;
- Confirming that the system is loaded with the patched kernel after the update.
Red Hat also indicates the possibility of limiting the loading of the tls module as a temporary measure, but the necessity of this measure should be assessed before applying it to organizational services.
2. CVE-2026-53266 — Memory corruption in ebtables SNAT mechanism
The second vulnerability, CVE-2026-53266, is related to the ebtables SNAT mechanism in the Linux kernel's network filtering system.
This vulnerability arises from not sufficiently verifying whether it is safe to write to the memory area intended for the sender's IP address when changing the source IP in ARP packets. According to Red Hat data, this can lead to local attacker memory corruption, service interruption, or in some cases, privilege escalation in systems with specific bridge/netfilter configurations.
How does the vulnerability pose a risk?
The Linux kernel can modify certain data when processing ARP packets. The problem is that a new IP address can be written to the corresponding memory area without full verification that it is ready.
In some special situations, this data may reside in memory pages that are commonly used or associated with files. As a result:
- corruption of memory content;
- alteration of files or data;
- kernel crash;
- interruption of service provision;
- or escalation of privileges under certain conditions may occur.
The important point is that to exploit this vulnerability, there must be specific ebtables/netfilter rules in the system. Furthermore, according to Red Hat data, it may be required to have the CAP_NET_ADMIN capability to modify the relevant network configuration.
This is particularly important for virtualization and container environments that use bridge networking.
Temporary protection
If immediate installation of the official update is not possible, Red Hat provides temporary measures such as:
- Disabling ebtables SNAT rules that modify the ARP IP address;
- Removing the relevant ebtables SNAT rules that operate on ARP traffic.
However, since these measures may affect network services, the existing infrastructure configuration must be assessed before applying them.
3. CVE-2025-39964 — Race condition in AF_ALG cryptographic interface
The third vulnerability, CVE-2025-39964, is related to the AF_ALG cryptographic interface in the Linux kernel.
AF_ALG allows user applications to use the Linux kernel's cryptographic functions.
The problem can occur when multiple write operations are sent to the same AF_ALG socket at the same time. In such a situation, data may intermingle unexpectedly, and there is a possibility that the internal state of the socket may be lost.
As a result:
- system or service crash;
- corruption of cryptographic operation results;
- loss of data integrity;
- and in some situations, other security consequences may arise.
The main cause of this vulnerability is that simultaneous writes to the same AF_ALG socket are allowed. The fix involves enforcing an exclusive ownership mechanism for write operations, allowing only one writer to send data via sendmsg().
Red Hat indicates the possibility of limiting the loading of the af_alg module as a temporary measure. However, since cryptographic services may depend on this module, such changes must be tested before use in production systems.
Main Differences of the Three Vulnerabilities
| CVE | Linux Component | Main Problem | Potential Consequence |
|---|---|---|---|
| CVE-2025-39682 | kTLS | Logical error in TLS data processing | Impact on system security and stability |
| CVE-2026-53266 | ebtables SNAT | Incorrect writing to memory | Memory corruption, DoS, potential privilege escalation |
| CVE-2025-39964 | AF_ALG | Race condition between writes | System crash and loss of data integrity |
Important Point: The exploitation conditions for all three vulnerabilities are not the same. For example, if CVE-2025-39682 depends on kTLS usage, CVE-2026-53266 requires specific bridge/netfilter configurations and corresponding authorities. CVE-2025-39964 is relevant for systems using the AF_ALG interface.
Therefore, instead of applying the same measure to all Linux systems, it is important to first determine which services and kernel functions are actually in use.
What measures should organizations take?
1. Update the Linux kernel promptly
Install security updates released by Linux distributions.
Important: Do not conclude that a system is vulnerable or protected based solely on the kernel version number. Ubuntu, Debian, Red Hat Enterprise Linux, SUSE, and other distributions may include security fixes in their packages at different times and in different version numbers. Therefore, it is necessary to check the official security bulletins and packages of the relevant distribution.
2. Reboot the server after the update
The server may still be running with the old kernel even after the kernel is updated.
Therefore:
- The installed kernel package;
- The active kernel version after the system reboot;
- Confirming that the update was successfully applied.
3. Identify the use of kTLS, ebtables, and AF_ALG
System administrators must answer the following questions:
- In which servers and services is kTLS being used?
- Are there any ebtables or bridge netfilter rules?
- Is SNAT used for ARP traffic?
- Are there any applications or services using the AF_ALG interface?
- Who and with what authority can access these functions?
This information helps to determine the actual scope of the vulnerability's impact.
4. Review CAP_NET_ADMIN privileges
It is important to check processes and containers with CAP_NET_ADMIN privileges, especially in container and virtualization environments.
Excessive Linux capabilities should be avoided.
5. Analyze Kernel and system logs
Updating is not the end of the process.
If the system has been running in a vulnerable state for a long time, security personnel should check for:
- Unexpected kernel errors;
- Unscheduled system reboots;
- Unusual privilege escalation situations;
- New or modified netfilter rules;
- Suspicious network configurations;
- Unknown processes;
- Unusual activities related to containers or namespaces.
6. Preserve evidence before updating
If there is a suspicion that the system has been exploited in a real attack, relevant evidence should be preserved before deleting all logs or unnecessarily reinstalling the system.
Specifically:
- Authentication logs;
- Kernel logs;
- Network traffic information;
- EDR/XDR telemetry;
- Firewall and IDS/IPS logs;
- System configuration;
- Changes to user and permissions should be preserved.
Is updating alone sufficient?
Not always.
The inclusion in CISA's KEV catalog indicates that these vulnerabilities are being exploited in real attacks. Therefore, if an organization's Linux server has a vulnerable version, it is important to check whether the system has been attacked or not before and during the update, rather than just updating it.
If suspicious activity is detected, the process of isolating the system, preserving evidence, and investigating the incident should be initiated.
The inclusion of CVE-2025-39682, CVE-2026-53266, and CVE-2025-39964 in the CISA KEV catalog is a serious warning for organizations. Since each of them relates to different functions of the Linux kernel, their exploitation conditions and potential consequences are different from each other.
Specifically, servers using kTLS, systems with bridge/netfilter configurations, container and virtualization infrastructures, and services using AF_ALG need to be checked separately.
Main recommendation for organizations: Update the Linux kernel as quickly as possible with security updates provided by the vendor, reboot servers with the patched kernel, verify the active kernel version, and conduct security checks during the period before the update.
Do not forget: Fixing the vulnerability is the first step of protection. Determining whether the system has been compromised or not is the second, important step.