Infinity Core CVE-2026-98260: kernel root bugs on CloudLinux

Infinity Core is a set of six Linux kernel bugs that researcher Hyunwoo Kim published on oss-security on 16 October 2026, with exploit code, once the distro embargo ended. They are local privilege escalations: any user who can run code on the box can try for root. On a shared cPanel or Plesk server that means every customer with SSH, cron, or a PHP shell dropped by a compromised WordPress site.

For CloudLinux the one that matters is CVE-2026-98260, a use-after-free in POSIX CPU timer cleanup. It affects CloudLinux 9 and 10, and fixed kernels are out for both. CloudLinux 10 also needs the signal fix. As of 19 October TuxCare reported no exploitation in the wild.

The six CVEs

Public root exploits target Ubuntu 26.04. On AlmaLinux and CloudLinux 9 and 10, TuxCare reproduced a crash with the timer bug but has not shown root. Don't read that as safe: the exploit is public and porting it is a matter of time.

Fixed kernels by branch

Plain AlmaLinux cPanel servers follow RHEL, which fixed the timer bug in RHEL 9 with RHSA-2026:86033 and in RHEL 10 with RHSA-2026:85321. Check the AlmaLinux errata for the matching build before you assume a box is clean.

Patch CloudLinux 9 and 10

uname -r
dnf update 'kernel*'
reboot

After the reboot, confirm the running kernel carries the fixes. Empty output means you are still exposed:

rpm -q --changelog kernel-core-$(uname -r) | grep -E 'CVE-2026-(98260|98256)'

Installing the package does nothing until you reboot into it. If you have several kernels installed, make sure GRUB boots the new one.

KernelCare status

KernelCare is the route for boxes you can't reboot this week. The futex livepatch has shipped. The timer livepatch for CVE-2026-98260 is in preparation, starting with CloudLinux 9, CloudLinux 10, and the Ubuntu kernels, but had not shipped as of 21 October. Pull the latest and check coverage:

kcarectl --update
kcarectl --patch-info | grep -E 'CVE-2026-(98260|98256|89754|80775)'

If you run ePortal, push the new feed through your channel rather than waiting for the schedule. Servers with Imunify360 may already have KernelCare included and just need it switched on.

Until you can patch

There is no sysctl, module blacklist, or user namespace switch that blocks these code paths. That's different from PwnEscape last week, where user.max_user_namespaces=0 closed the local route.

What you can do:

• Cut shell access. Remove SSH from accounts that don't need it and keep the rest on jailed shell. This doesn't stop a PHP webshell, but it shrinks the easy path.
• Move tenants who don't trust each other off shared-kernel containers and into separate VMs.
• Watch for crashes. A failed exploit attempt tends to oops:

journalctl -k | grep -iE 'BUG:|Oops|general protection'

An unexplained oops on a multi-user server is worth investigating as an attack. A clean log does not prove nothing happened.

Next steps

• Decide between reboot windows and livepatching with live patching for hosting fleets and KernelCare on cPanel servers.
• Cover every node with a KernelCare license, or a CloudLinux license for new servers.
• Still on CloudLinux 8? Plan the jump with migrating to CloudLinux OS 10.