CloudLinux administrators should check their kernel stream before treating CVE-2026-98276 as patched. The vendor’s November 7 advisory, updated at 22:30 UTC, describes different release states across its products.
Which update is available?
For CloudLinux 7h and 8, kernel 4.18.0-553.184.1.lve.1 is in staged rollout; a routine update reaches a server only when its rollout does. CloudLinux 7’s fix remains in preparation.
CloudLinux 8 LTS and 9 LTS have stable fixes starting at kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els17 and kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els17, respectively. Later builds also carry the fix. CloudLinux for Ubuntu 22.04 was still under investigation.
CloudLinux 9 and 10 use AlmaLinux kernels. AlmaLinux’s announcement identifies fixed builds 5.14.0-687.66.2.el9_8 and 6.12.0-211.74.2.el10_2 in testing. Those are not production-repository releases. Administrators considering that path should assess it as a testing-kernel deployment, following the vendor’s release-specific instructions.
The separate CloudLinux incident record says its CloudLinux 8 KernelCare livepatch reached the production feed on November 6 at 08:50 UTC. The newer advisory still lists livepatches for CloudLinux 9 and 10 as pending; the LTS streams require the fixed kernel.
A local attack with wider consequences
This is not a remotely triggered UDP packet vulnerability. Red Hat explains that a local attacker must win a race between concurrent socket operations. It rates the issue Moderate, with CVSS 7.0, while the kernel CNA score shown in its record is 7.8.
The upstream patch addresses an unlocked update to socket flags. A timestamp request racing with a UDP socket’s binding can erase the flag that delays freeing socket memory. The receive path may then access memory already freed. The fix takes the socket lock when enabling timestamping.
CloudLinux reports an exploit used against one CloudLinux 8 server on November 4, producing repeated crashes. Its incident record separately describes an unstable in-house root exploit on AlmaLinux 8. Root access was not demonstrated on the attacked server; these are different observations.
After a kernel update and reboot, compare uname -r with the fixed build for that stream. For KernelCare, use kcarectl --patch-info | grep CVE-2026-98276. AlmaLinux says firewall changes do not solve the local trigger; limiting who can run code only reduces exposure until patching.
