📋 TL;DR
Last updated 5 November 2026, 11:10 UTC
Infinity Core is a set of six Linux kernel local privilege escalation bugs (CVE-2026-98260, CVE-2026-98256, CVE-2026-89754, CVE-2026-80775, CVE-2026-98385, CVE-2026-97941), published with public exploit code on 16 October 2026.
On CloudLinux, the main exposure is the POSIX CPU timer bug, CVE-2026-98260. Public root exploits exist for other kernels. On CloudLinux 9 and 10, TuxCare reproduced a crash with the timer bug but has not shown root.
Six bugs in core kernel code, one disclosure. A researcher (Kim) published details and exploit code to oss-security on 16 October 2026, after the distribution embargo ended. TuxCare analyzed the six against its supported kernels and published its findings. This advisory applies that analysis to CloudLinux. As of 19 October, TuxCare reported no exploitation in the wild.
“Local” does not mean a customer you trust.
On a hosting server, the local attacker is whoever compromised one of the sites on it. Each of the six bugs is reachable from a plain unprivileged account: no capabilities, no user namespace, no special device access.
The code involved (exec, signals, timers, futexes, mincore()) is used by every process, so no unusual server configuration is needed. Shared servers where customers have SSH or control-panel shells are first in line.
Only the timer and signal bugs reach CloudLinux kernels. The futex bug is present in the CloudLinux 9 and 10 kernels but already fixed there, and its exploitability on CloudLinux 9 is not confirmed. The memory-management bug (CVE-2026-89754) affects no CloudLinux kernel. The scheduler and SLUB bugs (CVE-2026-98385, CVE-2026-97941) exist only in kernel 7.2 and later, which no CloudLinux kernel carries.
† CloudLinux for Ubuntu runs the stock Ubuntu kernel, so the fix arrives through Ubuntu security updates, not a CloudLinux stream. Ubuntu lists both linux and linux-hwe-6.8 on 22.04 as vulnerable to the timer bug, with no fix released.
“Under analysis” covers one bug only: the timer bug on the 4.18 and 3.10 kernels. The signal, memory-management, futex, scheduler, and SLUB code is absent there. On CloudLinux 8, the timer reproducer did not fire, and the vulnerable ordering has not been confirmed on 4.18.
A KernelCare livepatch is the no-reboot alternative on CloudLinux 9, 9 LTS, and 10.
No reliable one.
No sysctl, module blacklist, or switch that disables unprivileged user namespaces touches these code paths. CageFS does not help either: it isolates the file system view, but it does not filter the system calls involved, so a caged user can still trigger the bugs.
The remedy is a fixed kernel and a reboot, or a KernelCare livepatch. Until one is in place:
journalctl -k | grep -iE 'BUG:|Oops|general protection'
Status: 21 October 2026, 18:40 UTC. Analysis is in progress for the timer bug on these kernels. Code review so far finds none of the six vulnerable code paths on CloudLinux 7, and the CloudLinux 7h and 8 kernels share the 4.18 code base. No kernel update is needed yet. This section will be updated when the analysis completes.
Status: 21 October 2026, 18:40 UTC. Fixed kernels are released: 5.14.0-687.59.1.el9_8 for CloudLinux 9 and 6.12.0-211.67.1.el10_2 for CloudLinux 10, or later. The futex fix (CVE-2026-80775) came earlier, in 5.14.0-687.54.1.el9_8 and 6.12.0-211.63.1.el10_2.
Install the fixed kernel and reboot:
dnf update 'kernel*'
rebootUpdate: 5 November 2026, 11:10 UTC
The fixed TuxCare ELS kernel has been in the stable channel since 2 November: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els17 for CloudLinux 8 LTS and kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els17 for CloudLinux 9 LTS, or newer. A regular kernel update installs it, and a reboot starts the fixed kernel. Check the running version with uname -r. On CloudLinux 8 LTS this upgrade is the route to the fix, because that line has no KernelCare livepatch.
Status: 21 October 2026, 18:40 UTC. CloudLinux 8 LTS (5.14.0-284.1101.el8.tuxcare.11.els13) and CloudLinux 9 LTS (5.14.0-284.1101.el9.tuxcare.7.els20) carry the vulnerable timer code, found by code review and not reproduced. The fixed kernels are pending a TuxCare ELS release. TuxCare’s published analysis does not cover these two versions.
Update: 5 November 2026, 11:10 UTC
The livepatch for the timer bug (CVE-2026-98260) is on the main feed for CloudLinux 9 (since 22 October), CloudLinux 10 (since 26 October), and CloudLinux 9 LTS (since 30 October). The futex livepatch (CVE-2026-80775) reached the main feed for CloudLinux 10 on 2 November. A subscribed server takes them on its next update cycle, or on demand, with no reboot:
kcarectl --updateStatus: 21 October 2026, 18:40 UTC. The livepatch for the timer bug (CVE-2026-98260) is in preparation, starting with CloudLinux 9, CloudLinux 10, and the Ubuntu kernels. The futex livepatch (CVE-2026-80775) has been released. You can request patches on demand with kcarectl --update.
For the kernel streams, compare uname -r with the fixed version above, or a later one. Because distribution kernels backport fixes without changing the base version, do not judge exposure from the base kernel number.
On CloudLinux 9 and 10, you can also check that the running kernel carries the fix. Empty output means it is still exposed:
rpm -q --changelog kernel-core-$(uname -r) | grep -E 'CVE-2026-(98260|98256)'With KernelCare, check livepatch coverage:
kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'The rest of this advisory is background for readers who want it: how the attack plays out on a shared host, and the six bugs in outline. Neither is required to apply the update above.
A typical path starts at the web tier. Someone compromises one WordPress site through a plugin flaw and gets code running as that site’s user. With a working local root exploit, that foothold becomes root on the host, and every account on the server is within reach. Patching changes the ending: a web compromise stays one site to clean up, not a server to rebuild.
On CloudLinux 9 and 10, the root step is a credible risk even though TuxCare has so far shown only a crash: a working root exploit on another kernel means the same bug class can be turned into one. Other platform layers do not remove the exposure.
All six are memory-safety or race bugs in core kernel code.
Public root exploits exist for the timer, signal, memory-management, and futex bugs on a newer Ubuntu release, and for the scheduler bug on a rolling-release distribution with kernel 7.2. The SLUB bug has only a public trigger that panics the kernel. The 4.18 and 3.10 kernels are under analysis for the timer bug only.
Comments