Three KEV-listed Linux kernel CVEs (CVE-2025-39964, CVE-2026-53266, CVE-2025-39682): status and fixes for CloudLinux

On September 18, 2026, CISA added three Linux kernel vulnerabilities to its Known Exploited Vulnerabilities catalogue: a crypto-socket race (CVE-2025-39964), an ebtables bridge-firewall write (CVE-2026-53266), and a kernel-TLS flaw (CVE-2025-39682). They are unrelated bugs in different parts of the kernel, listed on the same day. This post says which CloudLinux versions each one affects and what to do about it.

All three need local access, and on a shared hosting server “local” is not only you and your staff. It is any process on the machine, including the PHP worker behind a customer’s compromised WordPress plugin. So “a local user could do this” means “whoever breaks into one site on the server could do this.” None of the three can be launched across the network, but on a shared host the attacker is often already inside one account.

Affected CloudLinux versions

This table answers whether a flaw is a live concern on each version. What to do about it is in the fix-status table further down.

Reading the icons. ❌ Affected means the flaw is present and an ordinary account can reach it. ⚠️ Present, out of reach by default means the vulnerable code is in the kernel but an ordinary account cannot reach it on the shipped configuration; the fix still hardens the server. ✅ Not affected means the version does not carry the flaw.

CVE-2025-39964: the crypto-socket flaw

The Linux kernel offers a programming interface, called AF_ALG, that lets ordinary programs ask the kernel to perform cryptographic work such as hashing and encryption. The flaw is a race: when two operations write to the same crypto socket at the same moment, their data interleaves and the socket’s internal state is left inconsistent.

Impact. Independent security researchers have published an exploit that turns this into full control of the machine, taking over a privileged process to gain root. It needs no special access to start, only an ordinary account on the server, and no particular configuration: the interface is open to every account on every one of these kernels.

Mitigation. There is none. The fix is the kernel update or livepatch. One idea does not work and is worth heading off, because it is the natural thing to try: you cannot disable the crypto interface by blocking a kernel module. On these kernels it is compiled into the kernel itself, not loaded as a separate module, so there is nothing to block. A blacklist entry or a boot parameter aimed at it is accepted without error and does nothing.

CVE-2026-53266: the bridge-firewall flaw

This flaw lives in the kernel’s bridge firewall, the part that filters traffic crossing a software network bridge. A firewall rule that rewrites the sender’s hardware address in ARP traffic can be made to write into memory it does not own, which can corrupt memory or escalate privileges.

The precondition. That rewrite rule is required: without it, the flaw cannot be triggered. What decides whether an ordinary account can create the rule is one platform setting, whether an account may build its own private network space. Where it can, a tenant can set up the bridge and the rule inside their own account and reach the flaw unaided. Where it cannot, the flaw is out of an ordinary account’s reach, though the fix still matters against a process that already holds network-administration rights.

Self-check. One command shows which side a server is on:

cat /proc/sys/user/max_user_namespaces

A value of 0 means the path is closed and an ordinary account cannot reach this flaw. Any other value means it is open.

Mitigation. Where the path is open and you do not need it, close it:

sysctl -w user.max_user_namespaces=0

This takes effect immediately, with no reboot, and removes a tenant’s route to the flaw. To make it persist across reboots, add user.max_user_namespaces = 0 to /etc/sysctl.conf (or a file in /etc/sysctl.d/). The cost is that it also stops ordinary accounts from using any feature that needs its own namespace, such as rootless containers, so it suits shared hosting rather than developer or container hosts.

CVE-2025-39682: the kernel-TLS flaw

Kernel TLS lets the kernel handle the encryption for a network connection directly, rather than leaving it to the application. The flaw is in how the kernel processes incoming records on such a connection. A zero-length record slips past a check meant to run on every record, so later data is handled under the wrong assumptions.

The precondition. Reaching it requires that kernel TLS actually be in use on a connection, which is uncommon on an ordinary web-hosting server, so the exposure is narrow.

Fix status by version

Each cell shows two routes to a fix: a kernel update, which every customer can take and which needs a reboot, and a KernelCare livepatch, which applies with no reboot if you run KernelCare. Each entry links to the stream that delivers it. We update this table as fixes land.

Update instructions

Each stream carries the status callouts we add as fixes land.

Stream 1: CloudLinux 7h and 8 kernel

Update the kernel and reboot:

yum update kernel
reboot

The bridge fix is in 4.18.0-553.142.1.lve and newer. The crypto kernel is in staged rollout; its version will appear here when it reaches the stable channel.

Stream 2: AlmaLinux kernel (CloudLinux 9 and 10)

Update the kernel and reboot:

dnf update kernel
reboot

CloudLinux 10: update to 6.12.0-211.59.1.el10_2 or newer, which carries all three fixes. CloudLinux 9: the current kernel carries the TLS and bridge fixes (the bridge fix from 5.14.0-687.23.1.el9_8); the crypto kernel is in preparation.

Stream 3: TuxCare ELS LTS kernel (CloudLinux 8 LTS and 9 LTS)

On an ELS-subscribed server, update and reboot:

dnf update
reboot

The bridge fix is in the current ELS kernel, kernel-lts-5.14.0-284.1101.tuxcare.11.els13 and newer. The crypto and TLS kernels are in preparation.

Stream 4: KernelCare livepatch

kcarectl --update

kcarectl --update --prefix test

Apply the latest livepatch, no reboot:

kcarectl --update

How to verify you are patched

If you run KernelCare, check all three CVEs at once; a server shows a line only for the ones that applied to it:

kcarectl --patch-info | grep -E 'CVE-2025-39964|CVE-2026-53266|CVE-2025-39682'

Use --patch-info, not --info. kcarectl --info prints only a patch-level summary and lists no CVEs, so it can make a patched server look unpatched.

If you took the kernel-update route instead, check the running kernel:

uname -r

Compare the result with the kernel version listed in your version’s stream above. A kernel at or above that version carries the fix.

Why this matters on a shared host

The crypto flaw exploit is the one that turns a single foothold into a server-wide problem on its own. An attacker who has broken into one hosted site is an ordinary local account. From there they open the kernel’s crypto interface, run the public exploit, and become root. Once an attacker is root, the per-account boundaries that keep one customer’s files, databases, and sessions away from another are enforced by a kernel the attacker now controls, and one compromised site becomes every site on the server. The bridge and TLS flaws are narrower, each gated by a condition that is not met everywhere. The crypto flaw is gated by nothing, the exploit is public, and closing it is worth a reboot or a livepatch on every server.

Technical details

CVE-2025-39964 (crypto socket). The AF_ALG interface lets user programs drive the kernel’s crypto. Its send path allowed two writers on one socket at once, so concurrent sendmsg() calls interleaved and left the per-socket request state inconsistent. The fix adds exclusive write ownership so only one writer proceeds at a time. The published exploit uses the resulting corruption to overwrite a privileged configuration value and gain root.

CVE-2026-53266 (bridge firewall). The ebtables SNAT target can rewrite the sender hardware address in ARP traffic. When that optional rewrite runs against certain network buffers, it writes past the intended region and into a memory page the sender does not own. Triggering it needs an ebtables SNAT rule with ARP rewriting on a bridge; the fix keeps the write in bounds.

CVE-2025-39682 (kernel TLS). On the kernel-TLS receive path, a zero-length record taken from an internal queue bypassed the per-read check that fixes the record type, so a following record could be processed under the wrong assumptions. The fix restores the check for that case. The flaw exists only in kernels that carry the affected receive-path code, which is why the older CloudLinux kernels are not affected.

References

• CISA Known Exploited Vulnerabilities catalogue (all three added September 18, 2026): catalogue
• Red Hat: CVE-2025-39964, CVE-2026-53266, CVE-2025-39682
• Upstream CVE records, with the fix commits: CVE-2025-39964, CVE-2026-53266, CVE-2025-39682
• AlmaLinux: ALSA-2026:70498 (CloudLinux 10, crypto), ALSA-2026:71233 (CloudLinux 10, bridge), ALSA-2026:70459 (CloudLinux 9, crypto)
• Ubuntu: CVE-2025-39964, CVE-2026-53266
• Related: bridge-stp-uaf (CVE-2026-72389) advisory, on the same private-network-space condition