CloudLinux is rolling out kernel fixes for CVE-2026-98276, a Linux flaw that lets any local user crash a server. On November 4, an exploit for it was used against a CloudLinux 8 server, which crashed 12 times. The attack on that server caused crashes only, but the company’s engineers have since turned the flaw into root access in their own tests.

On a shared server, every hosting account that can run a program counts as a local user, according to CloudLinux. So does an attacker who has broken into one vulnerable site. A crash takes every site on the server down with it. Root access would give an attacker every site, mailbox and database on the machine.

A Local Race Condition, Fixed Upstream in October

The flaw is a use-after-free, in which the kernel keeps using memory it has already released. A program races a timestamp request against a bind() call on its own UDP socket. When the two calls collide, the kernel can free the socket while its receive path may still be using it. The attack runs from inside the server, not over the network.

The kernel’s CVE team published the flaw on October 6, with a CVSS score of 7.8, rated High. The upstream fix takes the socket lock in sock_gettstamp(). It reached Linux 7.3-rc4 and all stable kernel lines before any exploitation was reported, so CloudLinux does not treat the flaw as a zero-day. Red Hat rates it Moderate, at 7.0, because winning the race is “difficult to achieve consistently.” CloudLinux describes its own privilege escalation exploit on AlmaLinux 8 as not stable but successful several times, and built on code taken from the attacked server. No exploit code is public.

Vercel Paid $50,000 for a KVM Escape That Has No CVE and No Patch. Every VPS Host Is Waiting for the Write-Up.

Fixed Kernels by Distribution, as of November 9

The upstream fix is a month old, and distribution kernels are arriving at different speeds. Other kernel variants, such as cloud kernels, can have a different status from the ones listed here.

SystemStatus
CloudLinux 7Fixed kernel in preparation
CloudLinux 7h and 8Kernel 4.18.0-553.184.1.lve.1 in staged rollout. KernelCare live patch for CloudLinux 8 since November 6
CloudLinux 8 LTS and 9 LTSTuxCare ELS kernels els17 and later, in the stable channel since November 2
CloudLinux 9 and 10Fixed kernels 5.14.0-687.66.2 and 6.12.0-211.74.2 in AlmaLinux’s testing repository
Red Hat Enterprise Linux 7 to 10Listed as affected, no fixed kernel listed
Ubuntu 22.04Standard 5.15 kernel fixed, 5.15.0-202.212. HWE 6.8 kernel fix pending
Ubuntu 24.04Standard kernel fix pending. HWE 7.0 kernel fixed
Debian 12 and 13Fixed in security updates

Installing a fixed kernel requires a reboot. KernelCare, CloudLinux’s live-patching service, applies the fix to a running kernel instead. So far, the live patch is out for CloudLinux 8, and CloudLinux lists none for the 8 LTS and 9 LTS kernels, which need the fixed kernel. According to CloudLinux’s status page, the KernelCare patch will most likely cover Enterprise Linux 8, 9 and 10 kernels, including RHEL, AlmaLinux, Rocky Linux and Oracle Linux. There is no date yet. CloudLinux for Ubuntu 22.04 gets its kernel from Canonical, and the company is still checking its status.

What Hosts Can Do Now

CloudLinux lists no mitigation. Any user who can open a UDP socket reaches the vulnerable code, and no sysctl or boot option turns it off. A firewall does not see the attack, because it runs through a program’s own calls to the kernel. According to CloudLinux, an SELinux policy could block those calls, but cPanel & WHM requires SELinux to be disabled. CageFS, which limits what each account can see of the file system, does not help, because the flaw is reached through sockets the account opens for itself.

The November 4 exploit leaves the same crash in the kernel log each time. On a server with a persistent journal, administrators can check the boot before the current one with the command CloudLinux published: journalctl -k -b -1 | grep -E 'inet_sock_destruct|udp_destruct_common|__sk_mem_raise_allocated|__udp_enqueue_schedule_skb'. Changing -1 to -2 or -3 checks earlier boots. A match is not proof of an attack on its own, and a clean log does not rule out an attack that did not crash the server.

Until a fix is installed, CloudLinux suggests restricting or suspending accounts that are not trusted, including shell access, cron jobs and customer applications that run their own programs. That lowers the risk without removing it.

Either a fixed kernel or the KernelCare patch closes the flaw. After a reboot into a fixed kernel, administrators can confirm the running version with uname -r. For KernelCare, the company points to kcarectl --patch-info | grep CVE-2026-98276, which prints lines naming the CVE on a patched server. The shorter command, kcarectl --info, does not list CVEs and can make a patched server look unpatched.