Monitoring - Patched kernels are now available for every affected CloudLinux platform, in addition to the KernelCare livepatches that have been on the main feed since August 4:
- CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-687.38.1.el9_8 or newer (ALSA-2026:53329)
- CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-211.46.1.el10_2 or newer (ALSA-2026:53330)
- CloudLinux for Ubuntu 22.04: Canonical kernel 5.15.0-190.200 or newer
(The fix shipped as an update to the current 9.8 and 10.2 kernel streams, earlier than the 9.9 / 10.3 releases mentioned in our July 31 update.)
A plain dnf update 'kernel*' (on Ubuntu: apt update and apt upgrade) followed by a reboot picks up the fix; update kmod-lve in the same run CloudLinux 8 is not affected. Servers running KernelCare are already protected and need no reboot
We are moving this incident to Monitoring and will resolve it once the kernel team confirms there is nothing further to release.
Aug 26, 2026 - 08:01 UTC
- CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-687.38.1.el9_8 or newer (ALSA-2026:53329)
- CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-211.46.1.el10_2 or newer (ALSA-2026:53330)
- CloudLinux for Ubuntu 22.04: Canonical kernel 5.15.0-190.200 or newer
(The fix shipped as an update to the current 9.8 and 10.2 kernel streams, earlier than the 9.9 / 10.3 releases mentioned in our July 31 update.)
A plain dnf update 'kernel*' (on Ubuntu: apt update and apt upgrade) followed by a reboot picks up the fix; update kmod-lve in the same run CloudLinux 8 is not affected. Servers running KernelCare are already protected and need no reboot
We are moving this incident to Monitoring and will resolve it once the kernel team confirms there is nothing further to release.
Aug 26, 2026 - 08:01 UTC
Update - KernelCare livepatches are now in the main feed for every affected CloudLinux platform: CloudLinux 9, CloudLinux 10, and CloudLinux for Ubuntu 22.04. Subscribed servers pick the patch up automatically on their next update cycle.
CloudLinux 8 has been confirmed as not affected, as the vulnerable code path is not present.
Aug 04, 2026 - 16:13 UTC
CloudLinux 8 has been confirmed as not affected, as the vulnerable code path is not present.
Aug 04, 2026 - 16:13 UTC
Update - Who is actually affected. Two things have to be true at once.
1) The kernel: el9_7 or newer on CloudLinux 9, el10_1 or newer on CloudLinux 10. Older kernels are not affected, so el9_6 and below and el10_0 are clear.
2) The module has to be on disk. Check the kernel:
uname -r
Then check the module:
ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null
If either check comes back clear, you have nothing to do.
Not affected, nothing to do. CloudLinux 7, CloudLinux 7 Hybrid, CloudLinux 8 LTS, CloudLinux 9 LTS.
CloudLinux 8 is still under investigation. Its kernel is a separate line from AlmaLinux 8 and the public exploit does not work against it. Apply the mitigation there anyway, as a precaution.
Extra layer, optional. The exploit needs a private user namespace to get CAP_NET_ADMIN. Take that away and it fails even if the module loads.
On CloudLinux 8, 9 and 10:
sysctl -w user.max_user_namespaces=0
On CloudLinux for Ubuntu 22.04:
sysctl -w kernel.unprivileged_userns_clone=0
To keep it after a reboot, write the same setting into /etc/sysctl.d/ovswrap.conf.
On Ubuntu, apparmor_restrict_unprivileged_userns does not help here. We tested it.
This layer does break things: rootless Docker and Podman, Snap and Flatpak sandboxes. Normal hosting is fine, so cPanel, Plesk, DirectAdmin and the language selectors are not affected. Skip this step unless you run Open vSwitch on purpose and cannot block the module.
Fix status. There is no patched AlmaLinux kernel for CloudLinux 9 or CloudLinux 10 yet. The fix should land in the AlmaLinux 9.9 and 10.3 kernels, and those follow Red Hat's schedule, so we cannot give you a date. CloudLinux for Ubuntu 22.04 gets its kernel from Canonical.
KernelCare patches for EL9 are out:
- CloudLinux 9 and AlmaLinux 9: K20260730_03
- RHEL 9: K20260730_01
- Rocky Linux 9: K20260730_08
- Oracle Linux 9: K20260730_06
The CloudLinux 9 patch sits in the testing feed. Take it now:
kcarectl --update --prefix test
EL10 patches are still being built, and CloudLinux for Ubuntu 22.04 is in preparation.
If you think a server was already hit. Patching now does not undo it. The public exploit ends by adding a sudoers rule and opening a root shell, so whoever got in keeps a way back. Check /etc/sudoers and every file in /etc/sudoers.d/ for entries your team did not add. Then look for accounts and SSH keys you do not recognize.
How to check you are covered. For the livepatch:
kcarectl --patch-info | grep CVE-2026-64531
Use --patch-info, not --info. The --info form prints nothing about single CVEs even on a patched server. For the kernel, compare uname -r against the target version once one exists. Full detail in the blog post.
Jul 31, 2026 - 12:47 UTC
1) The kernel: el9_7 or newer on CloudLinux 9, el10_1 or newer on CloudLinux 10. Older kernels are not affected, so el9_6 and below and el10_0 are clear.
2) The module has to be on disk. Check the kernel:
uname -r
Then check the module:
ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null
If either check comes back clear, you have nothing to do.
Not affected, nothing to do. CloudLinux 7, CloudLinux 7 Hybrid, CloudLinux 8 LTS, CloudLinux 9 LTS.
CloudLinux 8 is still under investigation. Its kernel is a separate line from AlmaLinux 8 and the public exploit does not work against it. Apply the mitigation there anyway, as a precaution.
Extra layer, optional. The exploit needs a private user namespace to get CAP_NET_ADMIN. Take that away and it fails even if the module loads.
On CloudLinux 8, 9 and 10:
sysctl -w user.max_user_namespaces=0
On CloudLinux for Ubuntu 22.04:
sysctl -w kernel.unprivileged_userns_clone=0
To keep it after a reboot, write the same setting into /etc/sysctl.d/ovswrap.conf.
On Ubuntu, apparmor_restrict_unprivileged_userns does not help here. We tested it.
This layer does break things: rootless Docker and Podman, Snap and Flatpak sandboxes. Normal hosting is fine, so cPanel, Plesk, DirectAdmin and the language selectors are not affected. Skip this step unless you run Open vSwitch on purpose and cannot block the module.
Fix status. There is no patched AlmaLinux kernel for CloudLinux 9 or CloudLinux 10 yet. The fix should land in the AlmaLinux 9.9 and 10.3 kernels, and those follow Red Hat's schedule, so we cannot give you a date. CloudLinux for Ubuntu 22.04 gets its kernel from Canonical.
KernelCare patches for EL9 are out:
- CloudLinux 9 and AlmaLinux 9: K20260730_03
- RHEL 9: K20260730_01
- Rocky Linux 9: K20260730_08
- Oracle Linux 9: K20260730_06
The CloudLinux 9 patch sits in the testing feed. Take it now:
kcarectl --update --prefix test
EL10 patches are still being built, and CloudLinux for Ubuntu 22.04 is in preparation.
If you think a server was already hit. Patching now does not undo it. The public exploit ends by adding a sudoers rule and opening a root shell, so whoever got in keeps a way back. Check /etc/sudoers and every file in /etc/sudoers.d/ for entries your team did not add. Then look for accounts and SSH keys you do not recognize.
How to check you are covered. For the livepatch:
kcarectl --patch-info | grep CVE-2026-64531
Use --patch-info, not --info. The --info form prints nothing about single CVEs even on a patched server. For the kernel, compare uname -r against the target version once one exists. Full detail in the blog post.
Jul 31, 2026 - 12:47 UTC
Update - We published the mitigation command with the wrong kind of quote marks. If you copied it from this page, the line in your config file is broken, the kernel ignored it, and the module was never blocked. The command is fixed now, but your server stays exposed until you redo it.
Fix it in three steps.
1. Look at the file:
cat -A /etc/modprobe.d/ovswrap.conf
It must hold exactly one line, install openvswitch /bin/false$. The $ is just the end of the line, cat -A adds it. Anything else on that line and the module is not blocked.
2. Write the file again:
printf 'install openvswitch /bin/false\n' > /etc/modprobe.d/ovswrap.conf
3. Test it. This command must fail:
modprobe openvswitch
And this one must print nothing:
lsmod | grep openvswitch
If step 3 prints a line, the module is already loaded. Unload it:
modprobe -r openvswitch.
Jul 31, 2026 - 12:29 UTC
Fix it in three steps.
1. Look at the file:
cat -A /etc/modprobe.d/ovswrap.conf
It must hold exactly one line, install openvswitch /bin/false$. The $ is just the end of the line, cat -A adds it. Anything else on that line and the module is not blocked.
2. Write the file again:
printf 'install openvswitch /bin/false\n' > /etc/modprobe.d/ovswrap.conf
3. Test it. This command must fail:
modprobe openvswitch
And this one must print nothing:
lsmod | grep openvswitch
If step 3 prints a line, the module is already loaded. Unload it:
modprobe -r openvswitch.
Jul 31, 2026 - 12:29 UTC
Update - * KernelCare patchsets for EL9:
K20260730_03: CL9 / AlmaLinux 9
K20260730_01: RHEL 9
K20260730_08: RockyLinux 9
K20260730_06: Oracle Linux 9
* KernelCare patchsets for EL10 are in progress.
Jul 30, 2026 - 18:13 UTC
K20260730_03: CL9 / AlmaLinux 9
K20260730_01: RHEL 9
K20260730_08: RockyLinux 9
K20260730_06: Oracle Linux 9
* KernelCare patchsets for EL10 are in progress.
Jul 30, 2026 - 18:13 UTC
Identified - OVSwrap (CVE-2026-64531) is a vulnerability in the Linux kernel’s Open vSwitch action validation that lets any local unprivileged user become root. A working public exploit exists. No CVSS score has been published yet.
Affected: CloudLinux 9, CloudLinux 10, and CloudLinux for Ubuntu 22.04. CloudLinux 8 is under investigation. → Affected CloudLinux versions
Am I exposed: run ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null. If it prints a path, yes. → Am I exposed?
Mitigation: one line, no reboot: echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf → Is there a mitigation?
Fix status:
Kernel patch, CloudLinux 9 and CloudLinux 10: no patched AlmaLinux kernel yet. → Stream 1
Kernel patch, CloudLinux for Ubuntu 22.04: arrives from Canonical. → Stream 2
KernelCare livepatch: available in the testing feed for CloudLinux 9. In preparation for CloudLinux 10 and CloudLinux for Ubuntu 22.04. → Stream 3
Verify: kcarectl --patch-info | grep CVE-2026-64531 for the livepatch, uname -r for the kernel. → How to verify you are patched
Why it matters: one compromised website on a shared server becomes root on the whole server. → Why this matters on a shared host
How the bug works: oversized nested actions wrap a 16-bit length field, so the kernel later parses attacker-controlled bytes as real instructions. → Technical details of the bug
Jul 30, 2026 - 17:59 UTC
Affected: CloudLinux 9, CloudLinux 10, and CloudLinux for Ubuntu 22.04. CloudLinux 8 is under investigation. → Affected CloudLinux versions
Am I exposed: run ls /lib/modules/$(uname -r)/kernel/net/openvswitch/openvswitch.ko* 2>/dev/null. If it prints a path, yes. → Am I exposed?
Mitigation: one line, no reboot: echo 'install openvswitch /bin/false' > /etc/modprobe.d/ovswrap.conf → Is there a mitigation?
Fix status:
Kernel patch, CloudLinux 9 and CloudLinux 10: no patched AlmaLinux kernel yet. → Stream 1
Kernel patch, CloudLinux for Ubuntu 22.04: arrives from Canonical. → Stream 2
KernelCare livepatch: available in the testing feed for CloudLinux 9. In preparation for CloudLinux 10 and CloudLinux for Ubuntu 22.04. → Stream 3
Verify: kcarectl --patch-info | grep CVE-2026-64531 for the livepatch, uname -r for the kernel. → How to verify you are patched
Why it matters: one compromised website on a shared server becomes root on the whole server. → Why this matters on a shared host
How the bug works: oversized nested actions wrap a 16-bit length field, so the kernel later parses attacker-controlled bytes as real instructions. → Technical details of the bug
Jul 30, 2026 - 17:59 UTC
After updating to WordPress 7.1.0 AccelerateWP enabled websites with CloudFlare CDN plugin crashed
Subscribe
Update - Recommended order of updates. Whether a site goes down depends on the order in which WordPress 7.1 and the AccelerateWP update arrive
If WordPress has not been upgraded to 7.1 yet:
Update AccelerateWP first, then upgrade WordPress. Plugin versions before 1.1-46 are not compatible with WordPress 7.1 (see the trigger conditions in our first update); if the site is already running 1.1-46 when the core upgrade happens, the outage does not occur at all
Update the package on the server. Until cloudlinux-site-optimization-module-1.1-46 reaches the stable channel, use one of the two commands from our 12:57 UTC update (beta or rollout slot 21 bypass). Refresh the plugin on each WordPress site so the site actually runs 1.1-46. Updating the package alone does not do this (see our 18:22 UTC update); the per-site command from that update is safe to run on a healthy site and keeps the plugin settings. Only then upgrade WordPress core to 7.1
If WordPress is already on 7.1 and the site is down: update the package and run the per-site reinstall from our 18:22 UTC update. It works on a site that is already failing
Aug 26, 2026 - 06:28 UTC
If WordPress has not been upgraded to 7.1 yet:
Update AccelerateWP first, then upgrade WordPress. Plugin versions before 1.1-46 are not compatible with WordPress 7.1 (see the trigger conditions in our first update); if the site is already running 1.1-46 when the core upgrade happens, the outage does not occur at all
Update the package on the server. Until cloudlinux-site-optimization-module-1.1-46 reaches the stable channel, use one of the two commands from our 12:57 UTC update (beta or rollout slot 21 bypass). Refresh the plugin on each WordPress site so the site actually runs 1.1-46. Updating the package alone does not do this (see our 18:22 UTC update); the per-site command from that update is safe to run on a healthy site and keeps the plugin settings. Only then upgrade WordPress core to 7.1
If WordPress is already on 7.1 and the site is down: update the package and run the per-site reinstall from our 18:22 UTC update. It works on a site that is already failing
Aug 26, 2026 - 06:28 UTC
Update - In addition to updating the cloudlinux-site-optimization-module package, the hosting provider also needs to update the plugin on all WordPress sites.
Updating the package refreshes only the copy of the plugin on disk at /opt/cloudlinux-site-optimization-module/clsop.zip. It does not touch the copy inside wp-content/plugins/clsop on each site, and a site picks the new version up on its own only if its owner turned on plugin auto-updates, which is off by default.
To refresh one site, run this as the site's own system user (not root) from the site document root, with the PHP binary that site runs:
/opt/clwpos/wp-cli-wrapped /opt/alt/php84/usr/bin/php /home/USER/public_html plugin install /opt/cloudlinux-site-optimization-module/clsop.zip --force --skip-plugins
(Make sure to change the PHP binary and document root paths accordingly)
This works on a site that is already showing the error and on a healthy one. It keeps the plugin active and keeps its settings. If you applied the hand edit from our first update, this replaces that file with the fixed version, so there is nothing to redo.
Aug 20, 2026 - 18:22 UTC
Updating the package refreshes only the copy of the plugin on disk at /opt/cloudlinux-site-optimization-module/clsop.zip. It does not touch the copy inside wp-content/plugins/clsop on each site, and a site picks the new version up on its own only if its owner turned on plugin auto-updates, which is off by default.
To refresh one site, run this as the site's own system user (not root) from the site document root, with the PHP binary that site runs:
/opt/clwpos/wp-cli-wrapped /opt/alt/php84/usr/bin/php /home/USER/public_html plugin install /opt/cloudlinux-site-optimization-module/clsop.zip --force --skip-plugins
(Make sure to change the PHP binary and document root paths accordingly)
This works on a site that is already showing the error and on a healthy one. It keeps the plugin active and keeps its settings. If you applied the hand edit from our first update, this replaces that file with the fixed version, so there is nothing to redo.
Aug 20, 2026 - 18:22 UTC
Monitoring - Fixed packages cloudlinux-site-optimization-module-1.1-46 are delivered to beta repository and rollout slot 21.
The package can be updated with the following commands:
yum update cloudlinux-site-optimization-module --enablerepo=cloudlinux-updates-testing
or
yum update cloudlinux-site-optimization-module --enablerepo=cloudlinux-rollout-21-bypass
Aug 20, 2026 - 12:57 UTC
The package can be updated with the following commands:
yum update cloudlinux-site-optimization-module --enablerepo=cloudlinux-updates-testing
or
yum update cloudlinux-site-optimization-module --enablerepo=cloudlinux-rollout-21-bypass
Aug 20, 2026 - 12:57 UTC
Identified - WordPress 7.1 changed how it builds the identifier for a hook callback. A callback registered as a closure now gets a numeric identifier, and PHP stores that as an integer array key. AccelerateWP passed the key to a string function, which is a fatal error under strict typing. The code runs on init, so both the front end and wp-admin go down.
Any AccelerateWP site on WordPress 7.1 where any installed plugin registers a closure on the deleted_post or transition_post_status hook. The Cloudflare plugin does not have to be installed, so a site with no Cloudflare plugin can be affected too. Sites on WordPress 6.9 or older are not affected.
A fix to be released in cloudlinux-site-optimization-module-1.1-46 today.
As a hotfix for your AccelerateWP-enabled WordPress instance, open the file wp-content/plugins/clsop/inc/ThirdParty/Plugins/CDN/Cloudflare.php and replace
substr( $key, - strlen( $method ) )
with
substr( (string) $key, - strlen( $method ) )
Aug 20, 2026 - 07:33 UTC
Any AccelerateWP site on WordPress 7.1 where any installed plugin registers a closure on the deleted_post or transition_post_status hook. The Cloudflare plugin does not have to be installed, so a site with no Cloudflare plugin can be affected too. Sites on WordPress 6.9 or older are not affected.
A fix to be released in cloudlinux-site-optimization-module-1.1-46 today.
As a hotfix for your AccelerateWP-enabled WordPress instance, open the file wp-content/plugins/clsop/inc/ThirdParty/Plugins/CDN/Cloudflare.php and replace
substr( $key, - strlen( $method ) )
with
substr( (string) $key, - strlen( $method ) )
Aug 20, 2026 - 07:33 UTC
Monitoring - The patched kernels are in the AlmaLinux production repositories:
CL9 / AlmaLinux 9 kernel-5.14.0-687.23.1.el9_8 or newer.
CL10 / AlmaLinux 10 kernel-6.12.0-211.31.1.el10_2 or newer.
A plain dnf update kernel followed by a reboot is sufficient. The testing-repository steps below are no longer needed.
Aug 25, 2026 - 22:19 UTC
CL9 / AlmaLinux 9 kernel-5.14.0-687.23.1.el9_8 or newer.
CL10 / AlmaLinux 10 kernel-6.12.0-211.31.1.el10_2 or newer.
A plain dnf update kernel followed by a reboot is sufficient. The testing-repository steps below are no longer needed.
Aug 25, 2026 - 22:19 UTC
Update - Patched kernel-lts package for CloudLinux 8 LTS and CloudLinux 9 LTS being prepared, installed from the TuxCare ELS repository, a pipeline separate from the stock CloudLinux 8 and 9 kernel rebuild. Install with yum update kernel-lts and reboot.
The KernelCare livepatch is available as a no-reboot alternative.
Jul 31, 2026 - 12:06 UTC
The KernelCare livepatch is available as a no-reboot alternative.
Jul 31, 2026 - 12:06 UTC
Update - NEW el9 / CL9 family:
-- K20260710_58 (rhel9)
-- K20260710_60 (almalinux9 = CL9)
-- K20260710_63 (oel9)
-- K20260710_65 (rockylinux9)
Still OPEN:
-- UEK:
uek6, uek7
-- amazon2
-- ubuntu-bionic
Jul 29, 2026 - 09:14 UTC
-- K20260710_58 (rhel9)
-- K20260710_60 (almalinux9 = CL9)
-- K20260710_63 (oel9)
-- K20260710_65 (rockylinux9)
Still OPEN:
-- UEK:
uek6, uek7
-- amazon2
-- ubuntu-bionic
Jul 29, 2026 - 09:14 UTC
Update - KernelCare livepatch for Januscape, by CloudLinux platform:
Fully rolled out on the main feed: CloudLinux 10 and CloudLinux for Ubuntu 22.04.
On the main feed (staged rollout): CloudLinux 8.
In the testing feed: CloudLinux 7h.
Still in preparation: CloudLinux 9.
Jul 11, 2026 - 03:15 UTC
Fully rolled out on the main feed: CloudLinux 10 and CloudLinux for Ubuntu 22.04.
On the main feed (staged rollout): CloudLinux 8.
In the testing feed: CloudLinux 7h.
Still in preparation: CloudLinux 9.
Jul 11, 2026 - 03:15 UTC
Update - Patched CloudLinux CL7h/CL8 kernels are released to the beta/testing channel. Target versions:
- CL7h kernel-4.18.0-553.139.3.lve.el7h or newer.
- CL8 kernel-4.18.0-553.139.3.lve.el8 or newer.
Promotion to the stable channel follows after the testing period.
AlmaLinux 9/10 has published patched kernels to its testing repository. Target versions:
- CL9 / AlmaLinux 9: kernel-5.14.0-687.20.3.el9_8 or newer.
- CL10 / AlmaLinux 10: kernel-6.12.0-211.30.3.el10_2 or newer.
For more detailed information and instructions on updating and mitigation, please visit our blog post: Januscape (CVE-2026-53359): Mitigation and Kernel Update on CloudLinux
Jul 07, 2026 - 17:08 UTC
- CL7h kernel-4.18.0-553.139.3.lve.el7h or newer.
- CL8 kernel-4.18.0-553.139.3.lve.el8 or newer.
Promotion to the stable channel follows after the testing period.
AlmaLinux 9/10 has published patched kernels to its testing repository. Target versions:
- CL9 / AlmaLinux 9: kernel-5.14.0-687.20.3.el9_8 or newer.
- CL10 / AlmaLinux 10: kernel-6.12.0-211.30.3.el10_2 or newer.
For more detailed information and instructions on updating and mitigation, please visit our blog post: Januscape (CVE-2026-53359): Mitigation and Kernel Update on CloudLinux
Jul 07, 2026 - 17:08 UTC
Identified - KernelCare is rolling out live patches for CVE-2026-53359 + CVE-2026-46113 (both required; tracked under the "CVE-2026-46113 and follow-up N-day kvm fixes" tickets).
Release state below is from the live release data
In feed now (by release):
EL10:
K20260703_15 (rhel10),
K20260703_16 (oel10),
K20260703_17 (rockylinux10),
K20260703_18 (almalinux10)
Debian 13: K20260706_09 (test feed)
Ubuntu Jammy: K20260706_01 (+ _02 arm64, _03 azure, _04 aws) (test feed)
Ubuntu Focal-on-Jammy-HWE: K20260706_06 (+ _05 azure, _07 aws) (test feed)
Proxmox VE 7 (5.15): K20260706_08 (test feed)
Not yet in any feed: el8, el9, ubuntu-noble, debian11, debian12, plain ubuntu-focal, uek6/uek7, ubuntu-bionic.
They are in active development (pushing to the release)
LibCare: out of scope (kernel-only).
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
Verify:
kcarectl --info | grep kpatch-build-time # build dated 2026-07 or later
kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113' # both fixes needed for Januscape
Hosts that do NOT run VMs but have KVM loaded by default — remove the attack surface entirely:
# unload now (fails if a VM is running → that host isn't a candidate)
sudo modprobe -r kvm_intel kvm # kvm_amd on AMD
# prevent load on boot ("install /bin/false" also blocks dependency/explicit loads,
# which a plain "blacklist" line does not)
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf
Verify: lsmod | grep kvm is empty and ls /dev/kvm → No such file. Revert: remove /etc/modprobe.d/disable-kvm.conf and modprobe kvm_intel (or reboot).
Hosts that DO run VMs — cannot unload; they depend on the livepatch. Partial hardening for the unprivileged-local vector on RHEL-family (where /dev/kvm is 0666) only:
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules
# then: sudo udevadm control --reload && sudo udevadm trigger (or reboot)
Perm-tightening does not stop a malicious VM guest — the guest→host escape still works via QEMU. Full coverage on a VM host = the livepatch.
Jul 07, 2026 - 15:10 UTC
Release state below is from the live release data
In feed now (by release):
EL10:
K20260703_15 (rhel10),
K20260703_16 (oel10),
K20260703_17 (rockylinux10),
K20260703_18 (almalinux10)
Debian 13: K20260706_09 (test feed)
Ubuntu Jammy: K20260706_01 (+ _02 arm64, _03 azure, _04 aws) (test feed)
Ubuntu Focal-on-Jammy-HWE: K20260706_06 (+ _05 azure, _07 aws) (test feed)
Proxmox VE 7 (5.15): K20260706_08 (test feed)
Not yet in any feed: el8, el9, ubuntu-noble, debian11, debian12, plain ubuntu-focal, uek6/uek7, ubuntu-bionic.
They are in active development (pushing to the release)
LibCare: out of scope (kernel-only).
How to update?
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
Verify:
kcarectl --info | grep kpatch-build-time # build dated 2026-07 or later
kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113' # both fixes needed for Januscape
How to mitigate until the patch will be available?
Hosts that do NOT run VMs but have KVM loaded by default — remove the attack surface entirely:
# unload now (fails if a VM is running → that host isn't a candidate)
sudo modprobe -r kvm_intel kvm # kvm_amd on AMD
# prevent load on boot ("install /bin/false" also blocks dependency/explicit loads,
# which a plain "blacklist" line does not)
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
| sudo tee /etc/modprobe.d/disable-kvm.conf
Verify: lsmod | grep kvm is empty and ls /dev/kvm → No such file. Revert: remove /etc/modprobe.d/disable-kvm.conf and modprobe kvm_intel (or reboot).
Hosts that DO run VMs — cannot unload; they depend on the livepatch. Partial hardening for the unprivileged-local vector on RHEL-family (where /dev/kvm is 0666) only:
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules
# then: sudo udevadm control --reload && sudo udevadm trigger (or reboot)
Perm-tightening does not stop a malicious VM guest — the guest→host escape still works via QEMU. Full coverage on a VM host = the livepatch.
Jul 07, 2026 - 15:10 UTC
Investigating - Confirmed exploitable in our lab.
Any KVM hypervisor host with the kvm_intel / kvm_amd modules loaded and /dev/kvm present is affected — i.e. the default posture on the KVM/enterprise fleet.
Impact ranges from host DoS (unprivileged, reliable) up to a full guest→host escape running as root .
On RHEL-family, /dev/kvm is world-accessible (0666), so an unprivileged local user can trigger it directly.
Jul 07, 2026 - 15:05 UTC
Any KVM hypervisor host with the kvm_intel / kvm_amd modules loaded and /dev/kvm present is affected — i.e. the default posture on the KVM/enterprise fleet.
Impact ranges from host DoS (unprivileged, reliable) up to a full guest→host escape running as root .
On RHEL-family, /dev/kvm is world-accessible (0666), so an unprivileged local user can trigger it directly.
Jul 07, 2026 - 15:05 UTC
Identified -
VsockDrop (CVE-2026-53365) is a local privilege escalation flaw in the Linux kernel's virtio vsock zerocopy send path. When a large MSG_ZEROCOPY send fragments across several socket buffers, only the last buffer carries the completion object the release path expects, so the kernel drops a page reference it never took. Combined with io_uring registered buffers, this frees a still-pinned page that gets reclaimed as page cache for /usr/bin/su, letting an ordinary unprivileged local user rewrite the interpreter path and reach root. No hypervisor, guest, or virtual machine is required — the vsock_loopback transport (VMADDR_CID_LOCAL) lets a process talk to itself locally. Scored 5.5 (Red Hat Moderate), but a working public exploit has been released.
Upstream, Linux kernels from 6.7 onward that have not taken the fix are affected.
- Ubuntu 24.04 (6.8 GA and 6.17 HWE, plus AWS/Azure/GCP/GKE variants): vulnerable, no Canonical fix released.
- Ubuntu 22.04 with HWE 6.8: vulnerable, no Canonical fix released.
- Ubuntu 26.04 and the 24.04 HWE 7.0 line: vulnerable, fixes in progress.
- RHEL 9 and 10, including the AlmaLinux, Rocky, Oracle and CloudLinux rebuilds: vulnerable code present, no vendor fix, but the public exploit is blocked as shipped by the io_uring default (kernel.io_uring_disabled = 2).
- Debian 13 trixie: fixed via DSA-6405-1 (original 6.12 release was vulnerable).
- Debian 12 bookworm on the optional 6.12 kernel needs DLA-4724-1.
Not affected: Ubuntu 22.04 GA on 5.15, Ubuntu 20.04/18.04, RHEL 8/7/6 and EL8 rebuilds, Debian 11.
Note: RHEL 9 reports a 5.14-based kernel numerically older than 6.7, but the feature (vsock MSG_ZEROCOPY) was backported.
1. Keep io_uring denied — on EL9/10 a value of 2 is already normal, so verify rather than change. On Ubuntu, disabling io_uring removes functionality apps may depend on (databases, proxies, high-throughput storage), so treat it as a real operational change; a value of 1 with kernel.io_uring_group can scope it to one group.
2. Remove the vsock transport where nothing needs it — blacklisting the module on bare metal with no vsock consumers is usually uneventful, but don't apply it blindly to a guest (QEMU guest agent, VMware Tools, nested virtualization all use vsock).
Check exposure with:
uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'
The KernelCare team is working on rebootless live patches for most affected distros. Patches are expected to be deployed in the next 24/48hs. Once patches land:
kcarectl --update
kcarectl --patch-info | grep 'CVE-2026-53365'
Where that returns nothing, don't read the absence as coverage or as a gap — confirm the exact kernel with support before removing a temporary mitigation.
Aug 20, 2026 - 06:30 UTC
Summary
VsockDrop (CVE-2026-53365) is a local privilege escalation flaw in the Linux kernel's virtio vsock zerocopy send path. When a large MSG_ZEROCOPY send fragments across several socket buffers, only the last buffer carries the completion object the release path expects, so the kernel drops a page reference it never took. Combined with io_uring registered buffers, this frees a still-pinned page that gets reclaimed as page cache for /usr/bin/su, letting an ordinary unprivileged local user rewrite the interpreter path and reach root. No hypervisor, guest, or virtual machine is required — the vsock_loopback transport (VMADDR_CID_LOCAL) lets a process talk to itself locally. Scored 5.5 (Red Hat Moderate), but a working public exploit has been released.
Affected Platforms
Upstream, Linux kernels from 6.7 onward that have not taken the fix are affected.
- Ubuntu 24.04 (6.8 GA and 6.17 HWE, plus AWS/Azure/GCP/GKE variants): vulnerable, no Canonical fix released.
- Ubuntu 22.04 with HWE 6.8: vulnerable, no Canonical fix released.
- Ubuntu 26.04 and the 24.04 HWE 7.0 line: vulnerable, fixes in progress.
- RHEL 9 and 10, including the AlmaLinux, Rocky, Oracle and CloudLinux rebuilds: vulnerable code present, no vendor fix, but the public exploit is blocked as shipped by the io_uring default (kernel.io_uring_disabled = 2).
- Debian 13 trixie: fixed via DSA-6405-1 (original 6.12 release was vulnerable).
- Debian 12 bookworm on the optional 6.12 kernel needs DLA-4724-1.
Not affected: Ubuntu 22.04 GA on 5.15, Ubuntu 20.04/18.04, RHEL 8/7/6 and EL8 rebuilds, Debian 11.
Note: RHEL 9 reports a 5.14-based kernel numerically older than 6.7, but the feature (vsock MSG_ZEROCOPY) was backported.
Mitigation
1. Keep io_uring denied — on EL9/10 a value of 2 is already normal, so verify rather than change. On Ubuntu, disabling io_uring removes functionality apps may depend on (databases, proxies, high-throughput storage), so treat it as a real operational change; a value of 1 with kernel.io_uring_group can scope it to one group.
2. Remove the vsock transport where nothing needs it — blacklisting the module on bare metal with no vsock consumers is usually uneventful, but don't apply it blindly to a guest (QEMU guest agent, VMware Tools, nested virtualization all use vsock).
Check exposure with:
uname -r
sysctl kernel.io_uring_disabled
lsmod | grep -E 'vsock|vmw_vsock'
Current Status
The KernelCare team is working on rebootless live patches for most affected distros. Patches are expected to be deployed in the next 24/48hs. Once patches land:
kcarectl --update
kcarectl --patch-info | grep 'CVE-2026-53365'
Where that returns nothing, don't read the absence as coverage or as a gap — confirm the exact kernel with support before removing a temporary mitigation.
Aug 20, 2026 - 06:30 UTC
Update - The fix for alt-mod-passenger is now available in the stable release.
Aug 19, 2026 - 09:41 UTC
Aug 19, 2026 - 09:41 UTC
Update - alt-mod-passenger is now available in beta:
Name : alt-mod-passenger
Version : 6.0.26
Release : 9.el9.cloudlinux
Architecture : x86_64
Size : 28 M
Source : alt-mod-passenger-6.0.26-9.el9.cloudlinux.src.rpm
Repository : cloudlinux-updates-testing
Summary : Phusion Passenger apache2 module
URL : http://www.cloudlinux.com
License : CloudLinux Commercial License
Description : Phusion Passenger module for Apache
ea-apache24-mod-passenger - cl-ea4 stable
Name : ea-apache24-mod-passenger
Epoch : 1
Version : 6.1.8
Release : 2.el9.cloudlinux
Architecture : x86_64
Size : 12 M
Source : ea-apache24-mod-passenger-6.1.8-2.el9.cloudlinux.src.rpm
Repository : @System
From repo : cl-ea4
Summary : Phusion Passenger application server
URL : https://www.phusionpassenger.com
License : Boost and BSD and BSD with advertising and MIT and zlib
Description : Phusion Passenger(r) is a web server and application server, designed to be fast,
: robust and lightweight. It takes a lot of complexity out of deploying web apps,
: adds powerful enterprise-grade features that are useful in production,
: and makes administration much easier and less complex. It supports Ruby,
: Python, Node.js and Meteor.
ea-ruby27-mod_passenger - cl-ea4 stable
Name : ea-ruby27-mod_passenger
Epoch : 1
Version : 6.1.8
Release : 2.el8.cloudlinux
Architecture : x86_64
Size : 46 M
Source : ea-ruby27-rubygem-passenger-6.1.8-2.el8.cloudlinux.src.rpm
Repository : @System
From repo : cl-ea4
Summary : Apache Module for Phusion Passenger
URL : https://www.phusionpassenger.com
License : Boost and BSD and BSD with advertising and MIT and zlib
Description : This package contains the pluggable Apache server module for Phusion Passenger(r).
Aug 17, 2026 - 19:10 UTC
Name : alt-mod-passenger
Version : 6.0.26
Release : 9.el9.cloudlinux
Architecture : x86_64
Size : 28 M
Source : alt-mod-passenger-6.0.26-9.el9.cloudlinux.src.rpm
Repository : cloudlinux-updates-testing
Summary : Phusion Passenger apache2 module
URL : http://www.cloudlinux.com
License : CloudLinux Commercial License
Description : Phusion Passenger module for Apache
ea-apache24-mod-passenger - cl-ea4 stable
Name : ea-apache24-mod-passenger
Epoch : 1
Version : 6.1.8
Release : 2.el9.cloudlinux
Architecture : x86_64
Size : 12 M
Source : ea-apache24-mod-passenger-6.1.8-2.el9.cloudlinux.src.rpm
Repository : @System
From repo : cl-ea4
Summary : Phusion Passenger application server
URL : https://www.phusionpassenger.com
License : Boost and BSD and BSD with advertising and MIT and zlib
Description : Phusion Passenger(r) is a web server and application server, designed to be fast,
: robust and lightweight. It takes a lot of complexity out of deploying web apps,
: adds powerful enterprise-grade features that are useful in production,
: and makes administration much easier and less complex. It supports Ruby,
: Python, Node.js and Meteor.
ea-ruby27-mod_passenger - cl-ea4 stable
Name : ea-ruby27-mod_passenger
Epoch : 1
Version : 6.1.8
Release : 2.el8.cloudlinux
Architecture : x86_64
Size : 46 M
Source : ea-ruby27-rubygem-passenger-6.1.8-2.el8.cloudlinux.src.rpm
Repository : @System
From repo : cl-ea4
Summary : Apache Module for Phusion Passenger
URL : https://www.phusionpassenger.com
License : Boost and BSD and BSD with advertising and MIT and zlib
Description : This package contains the pluggable Apache server module for Phusion Passenger(r).
Aug 17, 2026 - 19:10 UTC
Monitoring - The patched versions are already available in our stable repository.
Aug 15, 2026 - 04:04 UTC
Aug 15, 2026 - 04:04 UTC
Investigating - Phusion Passenger Watchdog API privilege escalation vulnerability:
https://support.cpanel.net/hc/en-us/articles/42694659893143-Security-Privilege-Escalation-via-Phusion-Passenger-s-Watchdog-API?utm_medium=email&_hsmi=433242580&utm_content=433242580&utm_source=hs_email
CloudLinux engineering is preparing and testing patched packages. Updated packages will be released shortly.
Aug 14, 2026 - 13:53 UTC
https://support.cpanel.net/hc/en-us/articles/42694659893143-Security-Privilege-Escalation-via-Phusion-Passenger-s-Watchdog-API?utm_medium=email&_hsmi=433242580&utm_content=433242580&utm_source=hs_email
CloudLinux engineering is preparing and testing patched packages. Updated packages will be released shortly.
Aug 14, 2026 - 13:53 UTC
Update - KernelCare Updates:
The following patchsets are available for ePortal -
- rhel10 (K20260812_0007)
- oel10 (K20260812_0008)
- rockylinux10 (K20260812_0009)
- almalinux10 (K20260812_0010)
Subscribed servers on those versions receive the patch automatically on the next update cycle, or immediately with kcarectl --update.
To check if you're patched, check build time with kcarectl --info | grep kpatch-build-time.
rhel10 -> build dated 2026-08-14 or later
oel10, rockylinux10, almalinux10 -> build dated 2026-08-17 or later
Aug 19, 2026 - 06:41 UTC
The following patchsets are available for ePortal -
- rhel10 (K20260812_0007)
- oel10 (K20260812_0008)
- rockylinux10 (K20260812_0009)
- almalinux10 (K20260812_0010)
Subscribed servers on those versions receive the patch automatically on the next update cycle, or immediately with kcarectl --update.
To check if you're patched, check build time with kcarectl --info | grep kpatch-build-time.
rhel10 -> build dated 2026-08-14 or later
oel10, rockylinux10, almalinux10 -> build dated 2026-08-17 or later
Aug 19, 2026 - 06:41 UTC
Update - KernelCare Updates:
The following patchsets are available for ePortal -
- debian12 (K20260811_12)
- ubuntu-noble kernel (K20260811_24)
- ubuntu-noble linux-aws (K20260811_25)
- pve-8 (K20260811_26)
- ubuntu-jammy linux-aws-6.8 (K20260811_27)
- debian11 (K20260811_28)
- rhel10 (K20260812_0007)
- oel10 (K20260812_0008)
- rockylinux10 (K20260812_0009)
- almalinux10 (K20260812_0010)
-debian13 (K20260812_0018) 0
- rhel9 (K20260813_0001)
- almalinux9 (K20260813_0003)
- oel9 (K20260813_0006)
- rockylinux9 (K20260813_0008)
- oel9-uek7 (K20260813_0011)
- oel8-uek7 (K20260813_0012)
In the testing feed:
ubuntu-jammy kernel (K20260817_0001) - this is for the generic 22.04 stream
Pending (almost ready for release):
EL8 family
Aug 18, 2026 - 21:32 UTC
The following patchsets are available for ePortal -
- debian12 (K20260811_12)
- ubuntu-noble kernel (K20260811_24)
- ubuntu-noble linux-aws (K20260811_25)
- pve-8 (K20260811_26)
- ubuntu-jammy linux-aws-6.8 (K20260811_27)
- debian11 (K20260811_28)
- rhel10 (K20260812_0007)
- oel10 (K20260812_0008)
- rockylinux10 (K20260812_0009)
- almalinux10 (K20260812_0010)
-debian13 (K20260812_0018) 0
- rhel9 (K20260813_0001)
- almalinux9 (K20260813_0003)
- oel9 (K20260813_0006)
- rockylinux9 (K20260813_0008)
- oel9-uek7 (K20260813_0011)
- oel8-uek7 (K20260813_0012)
In the testing feed:
ubuntu-jammy kernel (K20260817_0001) - this is for the generic 22.04 stream
Pending (almost ready for release):
EL8 family
Aug 18, 2026 - 21:32 UTC
Update - KernelCare livepatches for Zapscape are now in the main feed for:
CloudLinux 9
CloudLinux 10
Subscribed servers on those versions receive the patch automatically on the next update cycle, or immediately with kcarectl --update.
For CloudLinux 10:
The CVE tag is still being added to the CloudLinux 10 patch metadata, so kcarectl --patch-info | grep 'CVE-2026-64561' can return empty on a server that is already patched. Until the metadata lands, verify with kcarectl --info | grep kpatch-build-time instead (build dated August 12, 2026 or later).
Aug 14, 2026 - 04:01 UTC
CloudLinux 9
CloudLinux 10
Subscribed servers on those versions receive the patch automatically on the next update cycle, or immediately with kcarectl --update.
For CloudLinux 10:
The CVE tag is still being added to the CloudLinux 10 patch metadata, so kcarectl --patch-info | grep 'CVE-2026-64561' can return empty on a server that is already patched. Until the metadata lands, verify with kcarectl --info | grep kpatch-build-time instead (build dated August 12, 2026 or later).
Aug 14, 2026 - 04:01 UTC
Update - New KernelCare Releases:
debian12 (K20260811_12) 08-11 12:16
ubuntu-noble kernel (K20260811_24) 08-12 08:04
ubuntu-noble linux-aws (K20260811_25) 08-12 08:04
pve-8 (K20260811_26) 08-12 08:04
ubuntu-jammy linux-aws-6.8 (K20260811_27) 08-12 08:04
debian11 (K20260811_28) 08-12 08:04
rhel10 (K20260812_0007) 08-12 12:14 (CVE metadata missing)
oel10 (K20260812_0008) 08-13 07:13 (CVE metadata missing)
rockylinux10 (K20260812_0009) 08-13 07:13 (CVE metadata missing)
almalinux10 (K20260812_0010) 08-13 07:13 (CVE metadata missing)
rhel9 (K20260813_0001) 08-13 07:12
almalinux9 (K20260813_0003) 08-13 07:19
Aug 13, 2026 - 10:06 UTC
debian12 (K20260811_12) 08-11 12:16
ubuntu-noble kernel (K20260811_24) 08-12 08:04
ubuntu-noble linux-aws (K20260811_25) 08-12 08:04
pve-8 (K20260811_26) 08-12 08:04
ubuntu-jammy linux-aws-6.8 (K20260811_27) 08-12 08:04
debian11 (K20260811_28) 08-12 08:04
rhel10 (K20260812_0007) 08-12 12:14 (CVE metadata missing)
oel10 (K20260812_0008) 08-13 07:13 (CVE metadata missing)
rockylinux10 (K20260812_0009) 08-13 07:13 (CVE metadata missing)
almalinux10 (K20260812_0010) 08-13 07:13 (CVE metadata missing)
rhel9 (K20260813_0001) 08-13 07:12
almalinux9 (K20260813_0003) 08-13 07:19
Aug 13, 2026 - 10:06 UTC
Update - Available KernelCare patches containing the fix:
- Debian 13 release (K20260811_12)
- Ubuntu Noble release (K20260811_24)
- Ubuntu Noble for AWS (K20260811_25)
- Ubuntu Jammy for AWS 6.8 kernels (K20260811_27)
- Proxmox 8 release (K20260811_26)
Aug 12, 2026 - 13:09 UTC
- Debian 13 release (K20260811_12)
- Ubuntu Noble release (K20260811_24)
- Ubuntu Noble for AWS (K20260811_25)
- Ubuntu Jammy for AWS 6.8 kernels (K20260811_27)
- Proxmox 8 release (K20260811_26)
Aug 12, 2026 - 13:09 UTC
Update - CloudLinux kernel (CloudLinux 7h, CloudLinux 8). Patched kernels:
- CloudLinux 7h: kernel-4.18.0-553.150.1.lve.el7h or newer
- CloudLinux 8: kernel-4.18.0-553.150.1.lve.el8 or newer
The stable channel still carries 553.144.1, so a plain yum update kernel does not pick up this fix yet. The gradual rollout has reached slot 9. To take it right now on CloudLinux 8, either use the rollout bypass repository:
yum update 'kernel*' --enablerepo=cloudlinux-rollout-9-bypass
reboot
or the beta channel:
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot
On CloudLinux 7h:
yum update 'kernel*' --enablerepo=cl7h_beta
reboot
Once the kernels reach the stable channel, a plain yum update kernel; reboot is enough.
AlmaLinux kernel (CloudLinux 9, CloudLinux 10). Both are already fixed in the AlmaLinux production repositories, no testing repository needed:
- CloudLinux 9: kernel-5.14.0-687.30.1.el9_8 or newer (ALSA-2026:45192)
- CloudLinux 10: kernel-6.12.0-211.39.1.el10_2 or newer (ALSA-2026:45114)
The fix shipped in the July 24 upstream kernel batch, which predates the public disclosure of Zapscape, so a server that took a kernel update in the past two weeks may already be covered. Check with uname -r before planning a reboot window.
dnf update 'kernel*'
reboot
TuxCare ELS kernel (CloudLinux 8 LTS, CloudLinux 9 LTS). The patched kernel-lts package is in preparation. Once it ships, ELS-subscribed customers install it from the TuxCare ELS repository with yum update kernel-lts and reboot.
KernelCare livepatch. Not available for any CloudLinux platform yet. Livepatches are still in preparation for CloudLinux 7h, 8, 9 and 10. From the testing feed once available:
kcarectl --update --prefix test
Once promoted to the main feed, subscribed servers pick it up on the next update cycle, or on demand with kcarectl --update.
How to verify. For a kernel update, compare uname -r against the target version for your platform above. For the livepatch:
kcarectl --patch-info | grep 'CVE-2026-64561'
Use --patch-info for this. kcarectl --info | grep CVE-... comes back empty even on a correctly patched server.
Full advisory and per-platform instructions in the blog post.
Aug 11, 2026 - 13:34 UTC
- CloudLinux 7h: kernel-4.18.0-553.150.1.lve.el7h or newer
- CloudLinux 8: kernel-4.18.0-553.150.1.lve.el8 or newer
The stable channel still carries 553.144.1, so a plain yum update kernel does not pick up this fix yet. The gradual rollout has reached slot 9. To take it right now on CloudLinux 8, either use the rollout bypass repository:
yum update 'kernel*' --enablerepo=cloudlinux-rollout-9-bypass
reboot
or the beta channel:
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot
On CloudLinux 7h:
yum update 'kernel*' --enablerepo=cl7h_beta
reboot
Once the kernels reach the stable channel, a plain yum update kernel; reboot is enough.
AlmaLinux kernel (CloudLinux 9, CloudLinux 10). Both are already fixed in the AlmaLinux production repositories, no testing repository needed:
- CloudLinux 9: kernel-5.14.0-687.30.1.el9_8 or newer (ALSA-2026:45192)
- CloudLinux 10: kernel-6.12.0-211.39.1.el10_2 or newer (ALSA-2026:45114)
The fix shipped in the July 24 upstream kernel batch, which predates the public disclosure of Zapscape, so a server that took a kernel update in the past two weeks may already be covered. Check with uname -r before planning a reboot window.
dnf update 'kernel*'
reboot
TuxCare ELS kernel (CloudLinux 8 LTS, CloudLinux 9 LTS). The patched kernel-lts package is in preparation. Once it ships, ELS-subscribed customers install it from the TuxCare ELS repository with yum update kernel-lts and reboot.
KernelCare livepatch. Not available for any CloudLinux platform yet. Livepatches are still in preparation for CloudLinux 7h, 8, 9 and 10. From the testing feed once available:
kcarectl --update --prefix test
Once promoted to the main feed, subscribed servers pick it up on the next update cycle, or on demand with kcarectl --update.
How to verify. For a kernel update, compare uname -r against the target version for your platform above. For the livepatch:
kcarectl --patch-info | grep 'CVE-2026-64561'
Use --patch-info for this. kcarectl --info | grep CVE-... comes back empty even on a correctly patched server.
Full advisory and per-platform instructions in the blog post.
Aug 11, 2026 - 13:34 UTC
Identified - Zapscape (CVE-2026-64561) is a vulnerability in the Linux kernel’s KVM code.
For full technical details, visit the CloudLinux Security Blog:
https://blog.cloudlinux.com/zapscape-cve-2026-64561-kvm-guest-escape-and-local-root-mitigation-and-kernel-update-for-cloudlinux/
Aug 10, 2026 - 15:19 UTC
For full technical details, visit the CloudLinux Security Blog:
https://blog.cloudlinux.com/zapscape-cve-2026-64561-kvm-guest-escape-and-local-root-mitigation-and-kernel-update-for-cloudlinux/
Aug 10, 2026 - 15:19 UTC
Identified -
BadGarbage (CVE-2026-53361, CVSS 7.0) is a vulnerability tied to a race condition in the Linux kernel’s Unix-socket garbage collector. Any local user, including a process inside a container, can exploit the flaw to become root on the host. A public working proof-of-concept exists.
CloudLinux 10.
None at runtime; the fix is a patched kernel or a KernelCare livepatch.
- Patched Kernel:
The fix for BadGarbage comes from AlmaLinux’s patched kernel "6.12.0-211.47.1.el10_2", which is available in the stable repository. To update, run:
dnf update 'kernel*'
reboot
- KernelCare
The KernelCare livepatch for CVE-2026-53361 is in preparation.
Aug 18, 2026 - 22:03 UTC
Summary
BadGarbage (CVE-2026-53361, CVSS 7.0) is a vulnerability tied to a race condition in the Linux kernel’s Unix-socket garbage collector. Any local user, including a process inside a container, can exploit the flaw to become root on the host. A public working proof-of-concept exists.
Affected Platforms
CloudLinux 10.
Mitigation
None at runtime; the fix is a patched kernel or a KernelCare livepatch.
Current Status
- Patched Kernel:
The fix for BadGarbage comes from AlmaLinux’s patched kernel "6.12.0-211.47.1.el10_2", which is available in the stable repository. To update, run:
dnf update 'kernel*'
reboot
- KernelCare
The KernelCare livepatch for CVE-2026-53361 is in preparation.
Aug 18, 2026 - 22:03 UTC
Identified -
A local privilege escalation vulnerability has been identified that allows an unprivileged user (uid=1000) to escalate to root within the initial namespace. The issue was reproduced on stock Ubuntu 22.04.5, kernel 5.15.0-187-generic (5.15.0-187.197), on a four-vCPU VM with memory-cgroup accounting enabled and nokaslr as the only exploit-specific boot argument.
The exploit was independently verified beyond its own reported success output: a persistent journald oops captured during a successful run cross-matches the forged modprobe_path write at the instruction level.
Exploitation is unreliable and disruptive when it fails — approximately 1 success in 8 attempts, with 6 of the 8 failed attempts causing a kernel oops or hang.
Any kernel containing commit 470502de5bdb is affected — this corresponds to Linux 5.1 and later, including vendor backports that carry this commit. CloudLinux kernels are detailed below:
- CloudLinux 7 (3.10) — Not affected, predates the vulnerable code. No action.
- CloudLinux 7 Hybrid (4.18) — Affected. User namespaces enabled by default; corruption and host panic confirmed. Action required.
- CloudLinux 8 (4.18) — Affected. User namespaces enabled by default; corruption confirmed. Action required.
- CloudLinux 8 LTS (5.14, TuxCare ELS) — Code present, stock config blocks the exploit (user.max_user_namespaces=0).
- CloudLinux 9 (5.14) — Code present, stock config blocks the exploit.
- CloudLinux 9 LTS (5.14, TuxCare ELS) — Code present, stock config blocks the exploit.
- CloudLinux 10 (6.12) — Code present, stock config blocks the exploit.
- CloudLinux for Ubuntu 22.04 (5.15) — Code present, blocked by the CloudLinux sysctl overlay at /etc/sysctl.d/90-cloudlinux.conf.
Recommended on CloudLinux 8 and CloudLinux 7 Hybrid (no reboot required):
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-rtabrace.conf
sysctl -p /etc/sysctl.d/99-rtabrace.conf
- CloudLinux 7 hybrid and 8: The upstream fix is being backported. Still in progress.
- CloudLinux 9 and 10: In progress.
- CloudLinux for Ubuntu 22.04: kernel fix comes from Canonical through Ubuntu USN.
- KernelCare patchsets are currently in progress for the affected CloudLinux platforms.
Aug 14, 2026 - 10:50 UTC
Summary
A local privilege escalation vulnerability has been identified that allows an unprivileged user (uid=1000) to escalate to root within the initial namespace. The issue was reproduced on stock Ubuntu 22.04.5, kernel 5.15.0-187-generic (5.15.0-187.197), on a four-vCPU VM with memory-cgroup accounting enabled and nokaslr as the only exploit-specific boot argument.
Verification
The exploit was independently verified beyond its own reported success output: a persistent journald oops captured during a successful run cross-matches the forged modprobe_path write at the instruction level.
Reliability
Exploitation is unreliable and disruptive when it fails — approximately 1 success in 8 attempts, with 6 of the 8 failed attempts causing a kernel oops or hang.
Affected Platforms
Any kernel containing commit 470502de5bdb is affected — this corresponds to Linux 5.1 and later, including vendor backports that carry this commit. CloudLinux kernels are detailed below:
- CloudLinux 7 (3.10) — Not affected, predates the vulnerable code. No action.
- CloudLinux 7 Hybrid (4.18) — Affected. User namespaces enabled by default; corruption and host panic confirmed. Action required.
- CloudLinux 8 (4.18) — Affected. User namespaces enabled by default; corruption confirmed. Action required.
- CloudLinux 8 LTS (5.14, TuxCare ELS) — Code present, stock config blocks the exploit (user.max_user_namespaces=0).
- CloudLinux 9 (5.14) — Code present, stock config blocks the exploit.
- CloudLinux 9 LTS (5.14, TuxCare ELS) — Code present, stock config blocks the exploit.
- CloudLinux 10 (6.12) — Code present, stock config blocks the exploit.
- CloudLinux for Ubuntu 22.04 (5.15) — Code present, blocked by the CloudLinux sysctl overlay at /etc/sysctl.d/90-cloudlinux.conf.
Mitigation
Recommended on CloudLinux 8 and CloudLinux 7 Hybrid (no reboot required):
echo 'user.max_user_namespaces = 0' > /etc/sysctl.d/99-rtabrace.conf
sysctl -p /etc/sysctl.d/99-rtabrace.conf
Current Status
- CloudLinux 7 hybrid and 8: The upstream fix is being backported. Still in progress.
- CloudLinux 9 and 10: In progress.
- CloudLinux for Ubuntu 22.04: kernel fix comes from Canonical through Ubuntu USN.
- KernelCare patchsets are currently in progress for the affected CloudLinux platforms.
Aug 14, 2026 - 10:50 UTC
Identified - The `pam_lve 0.4-5` update, delivered via gradual rollout Slot #3, added audit logging of LVE entry/exemption decisions. Due to a defect in how these messages are emitted, the module alters the process-wide syslog facility of the calling service. The most visible effect is on cron: after a pam_lve message is logged, subsequent cron records may be tagged with the `auth` facility instead of `cron`, so they appear in `/var/log/messages` instead of `/var/log/cron` (in journald: `SYSLOG_FACILITY=4` instead of `9`). Tools that rely on the cron facility (logwatch, fail2ban, SIEM agents) may also be confused.
**LVE resource limits, CageFS, and system security are NOT affected — this is a log-routing issue only.** The new log lines themselves (e.g. `pam_lve: User root (UID 0) exempted from LVE: UID below min_uid threshold`) are intended audit logging; only their side effect on the syslog facility is a defect.
To check whether a server is affected: `rpm -q pam_lve` — version 0.4-5 is affected, 0.4-3 is not.
## Slot pause
We have paused rollout Slot #3. No new servers will receive these packages until a fixed build is published. Servers that already installed the update keep the current packages — there is no automatic downgrade. The root cause has been identified, and a fix is in progress.
## Affected packages (Slot #3 contents)
- `pam_lve-0.4-5` — CloudLinux 7, 8, 9, 10 (`pam-lve 0.4-5` on Ubuntu) — contains the issue
- `bsock-0.10-1` — CloudLinux 7–10, Ubuntu — no known issues; paused only because it shipped in the same slot. No action needed for bsock.
## ETA
A fixed pam_lve build is expected within **1–2 business days**. The rollout will then resume with the corrected package, and servers already on 0.4-5 will receive the fix through the resumed rollout.
## Mitigation for affected servers (optional)
If the logging behavior causes problems, either option below resolves it; otherwise, you can simply wait for the fixed package.
**Option A** — downgrade pam_lve to the stable version (0.4-3). Takes effect for new sessions immediately; no service restart or reboot required:
```
yum clean all && yum downgrade pam_lve
```
Ubuntu:
```
apt-get update && apt-get install --allow-downgrades pam-lve=0.4-3
```
**Option B** — keep 0.4-5 and route cron logs by program name instead of facility (rsyslog):
```
cat > /etc/rsyslog.d/00-cron.conf <
if ($programname == "CROND" or $programname == "crond" or $programname == "anacron" or $programname == "run-parts") then {
action(type="omfile" file="/var/log/cron")
stop
}
EOF
systemctl restart rsyslog
```
## Package manager errors after the pause
If yum/dnf reports errors for the rollout slot repository after the pause (e.g., `Failed to download metadata for repo 'cloudlinux-rollout-3'` or a 404 on `repomd.xml`), clear the cached metadata and retry:
```
yum clean all
```
(Ubuntu: `apt-get update`.) The error is transient and does not affect other repositories.
Aug 17, 2026 - 18:44 UTC
**LVE resource limits, CageFS, and system security are NOT affected — this is a log-routing issue only.** The new log lines themselves (e.g. `pam_lve: User root (UID 0) exempted from LVE: UID below min_uid threshold`) are intended audit logging; only their side effect on the syslog facility is a defect.
To check whether a server is affected: `rpm -q pam_lve` — version 0.4-5 is affected, 0.4-3 is not.
## Slot pause
We have paused rollout Slot #3. No new servers will receive these packages until a fixed build is published. Servers that already installed the update keep the current packages — there is no automatic downgrade. The root cause has been identified, and a fix is in progress.
## Affected packages (Slot #3 contents)
- `pam_lve-0.4-5` — CloudLinux 7, 8, 9, 10 (`pam-lve 0.4-5` on Ubuntu) — contains the issue
- `bsock-0.10-1` — CloudLinux 7–10, Ubuntu — no known issues; paused only because it shipped in the same slot. No action needed for bsock.
## ETA
A fixed pam_lve build is expected within **1–2 business days**. The rollout will then resume with the corrected package, and servers already on 0.4-5 will receive the fix through the resumed rollout.
## Mitigation for affected servers (optional)
If the logging behavior causes problems, either option below resolves it; otherwise, you can simply wait for the fixed package.
**Option A** — downgrade pam_lve to the stable version (0.4-3). Takes effect for new sessions immediately; no service restart or reboot required:
```
yum clean all && yum downgrade pam_lve
```
Ubuntu:
```
apt-get update && apt-get install --allow-downgrades pam-lve=0.4-3
```
**Option B** — keep 0.4-5 and route cron logs by program name instead of facility (rsyslog):
```
cat > /etc/rsyslog.d/00-cron.conf <
if ($programname == "CROND" or $programname == "crond" or $programname == "anacron" or $programname == "run-parts") then {
action(type="omfile" file="/var/log/cron")
stop
}
EOF
systemctl restart rsyslog
```
## Package manager errors after the pause
If yum/dnf reports errors for the rollout slot repository after the pause (e.g., `Failed to download metadata for repo 'cloudlinux-rollout-3'` or a 404 on `repomd.xml`), clear the cached metadata and retry:
```
yum clean all
```
(Ubuntu: `apt-get update`.) The error is transient and does not affect other repositories.
Aug 17, 2026 - 18:44 UTC
Update - KernelCare livepatch status for GhostLock, brought up to date. The livepatch is on the main feed for CloudLinux 7, CloudLinux 7 Hybrid, CloudLinux 8, CloudLinux 9 (including AlmaLinux 9 and CloudLinux 9 LTS), CloudLinux 10, and CloudLinux for Ubuntu 22.04. Nothing in the CloudLinux family is testing-only at this point, so a subscribed server takes the patch on its next update cycle, or on demand.
kcarectl --update
One caveat on CloudLinux 7. The patch there (K20260721_69) covers the lve1.5.80 through lve1.5.88 kernel builds only. On a CL7 server running lve1.5.79 or older there is no livepatch for that build, and the kernel update is the only route. Those kernels are on the stable channel already.
yum update 'kernel*'
reboot
Check which build you are on with uname -r, and confirm the livepatch with:
kcarectl --patch-info | grep CVE-2026-43499
Use --patch-info, not --info, which comes back empty even on a patched server.
Jul 31, 2026 - 13:09 UTC
kcarectl --update
One caveat on CloudLinux 7. The patch there (K20260721_69) covers the lve1.5.80 through lve1.5.88 kernel builds only. On a CL7 server running lve1.5.79 or older there is no livepatch for that build, and the kernel update is the only route. Those kernels are on the stable channel already.
yum update 'kernel*'
reboot
Check which build you are on with uname -r, and confirm the livepatch with:
kcarectl --patch-info | grep CVE-2026-43499
Use --patch-info, not --info, which comes back empty even on a patched server.
Jul 31, 2026 - 13:09 UTC
Update - Patched kernels for GhostLock have been promoted to the stable channel - a plain update now pulls the fix, no testing-repo flag needed:
- CL7: kernel-3.10.0-962.3.2.lve1.5.89.el7 or newer
- CL7h: kernel-4.18.0-553.141.2.lve.el7h or newer
- CL8: kernel-4.18.0-553.141.2.lve.el8 or newer
Run:
yum update 'kernel*'
reboot
AlmaLinux 9/10 production repos now carry newer point releases (AL9 687.26.1, AL10 211.34.1) — both still satisfy the original GhostLock fix target.
Jul 22, 2026 - 11:33 UTC
- CL7: kernel-3.10.0-962.3.2.lve1.5.89.el7 or newer
- CL7h: kernel-4.18.0-553.141.2.lve.el7h or newer
- CL8: kernel-4.18.0-553.141.2.lve.el8 or newer
Run:
yum update 'kernel*'
reboot
AlmaLinux 9/10 production repos now carry newer point releases (AL9 687.26.1, AL10 211.34.1) — both still satisfy the original GhostLock fix target.
Jul 22, 2026 - 11:33 UTC
Update - KernelCare livepatches for GhostLock are now fully rolled out on the main feed for CloudLinux 7h, CloudLinux 8, CloudLinux 9 (including AlmaLinux 9 and CloudLinux 9 LTS, patch K20260710_14), and CloudLinux for Ubuntu 22.04. Subscribed servers receive the fix automatically on the next update cycle: run kcarectl --update to apply on demand.
AlmaLinux 8/9/10 patched kernels are now available in the production repositories (testing-repo activation is no longer needed):
- AL8: kernel-4.18.0-553.141.2.el8_10 or newer
- AL9: kernel-5.14.0-687.24.1.el9_8 or newer
- AL10: kernel-6.12.0-211.32.1.el10_2 or newer
A plain dnf clean metadata && dnf upgrade followed by reboot picks up the fix. Verify with kcarectl --patch-info | grep CVE-2026-43499.
Full per-platform details are in the blog post.
Jul 14, 2026 - 12:58 UTC
AlmaLinux 8/9/10 patched kernels are now available in the production repositories (testing-repo activation is no longer needed):
- AL8: kernel-4.18.0-553.141.2.el8_10 or newer
- AL9: kernel-5.14.0-687.24.1.el9_8 or newer
- AL10: kernel-6.12.0-211.32.1.el10_2 or newer
A plain dnf clean metadata && dnf upgrade followed by reboot picks up the fix. Verify with kcarectl --patch-info | grep CVE-2026-43499.
Full per-platform details are in the blog post.
Jul 14, 2026 - 12:58 UTC
Update - Reminder for the kernel-update path: update the LVE kernel module kmod-lve in the same run as the kernel. The patched kernel keeps the same KABI, so a current module stays compatible, but a host coming from a much older kernel can end up with an incompatible kmod-lve; update both together to avoid a module/kernel mismatch.
CL8 (beta):
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
yum update kmod-lve --enablerepo=cloudlinux-updates-testing
reboot
CL7h uses --enablerepo=cl7h_beta for the kernel;
CL9/CL10 add dnf update kmod-lve --enablerepo=cloudlinux-updates-testing before reboot.
Full instructions in the blog post
Jul 13, 2026 - 11:44 UTC
CL8 (beta):
yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
yum update kmod-lve --enablerepo=cloudlinux-updates-testing
reboot
CL7h uses --enablerepo=cl7h_beta for the kernel;
CL9/CL10 add dnf update kmod-lve --enablerepo=cloudlinux-updates-testing before reboot.
Full instructions in the blog post
Jul 13, 2026 - 11:44 UTC
Update - The patched CloudLinux 7 kernel is in the beta/testing channel, and rollout to stable has started. You may install from the testing channel now. Target version:
CL7: kernel-3.10.0-962.3.2.lve1.5.89.el7 or newer
The CloudLinux 7 KernelCare livepatch is now in the testing feed, with promotion to the main feed to follow.
Jul 11, 2026 - 03:12 UTC
CL7: kernel-3.10.0-962.3.2.lve1.5.89.el7 or newer
The CloudLinux 7 KernelCare livepatch is now in the testing feed, with promotion to the main feed to follow.
Jul 11, 2026 - 03:12 UTC
Update - Released in test feed:
rhel7 K20260710_48
oel7 K20260710_49
cl7 K20260710_52
oel8-uek6 K20260710_46
oel7-uek6 K20260710_45
amazon2 K20260710_47
EL8 (not previously listed):
almalinux8 - K20260710_41 (general kernel, test);
rhel8 - K20260710_28 — kernel-eus-8.6 only ⚠️ (general RHEL8/CL8 not covered).
EL10 + Debian 12 in test
rhel10 - K20260710_20,
almalinux10 - K20260710_23,
rockylinux10 - K20260710_22,
oel10 - K20260710_21,
debian12 - K20260710_24
Jul 10, 2026 - 15:46 UTC
rhel7 K20260710_48
oel7 K20260710_49
cl7 K20260710_52
oel8-uek6 K20260710_46
oel7-uek6 K20260710_45
amazon2 K20260710_47
EL8 (not previously listed):
almalinux8 - K20260710_41 (general kernel, test);
rhel8 - K20260710_28 — kernel-eus-8.6 only ⚠️ (general RHEL8/CL8 not covered).
EL10 + Debian 12 in test
rhel10 - K20260710_20,
almalinux10 - K20260710_23,
rockylinux10 - K20260710_22,
oel10 - K20260710_21,
debian12 - K20260710_24
Jul 10, 2026 - 15:46 UTC
Update - New patches available in the main feed:
rhel9 - K20260709_03
almalinux9 - K20260709_05
oel9 - K20260709_08
rockylinux9 - K20260709_10
Jul 10, 2026 - 11:32 UTC
rhel9 - K20260709_03
almalinux9 - K20260709_05
oel9 - K20260709_08
rockylinux9 - K20260709_10
Jul 10, 2026 - 11:32 UTC
Update - New patches available for the following systems:
pve-8 - K20260710_04
ubuntu-noble - K20260710_02
almalinux9 LTS - K20260710_14
almalinux9 FIPS 9.6 - K20260710_01
kcarectl --patch-info will reference only CVE-2026-43499 (53166 is not cited), so finding CVE-2026-43499 is sufficient to confirm GhostLock is patched.
the follow-up fix CVE-2026-53166 was reverted upstream (regression)
EL6 distros has low priority
Jul 10, 2026 - 09:52 UTC
pve-8 - K20260710_04
ubuntu-noble - K20260710_02
almalinux9 LTS - K20260710_14
almalinux9 FIPS 9.6 - K20260710_01
kcarectl --patch-info will reference only CVE-2026-43499 (53166 is not cited), so finding CVE-2026-43499 is sufficient to confirm GhostLock is patched.
the follow-up fix CVE-2026-53166 was reverted upstream (regression)
EL6 distros has low priority
Jul 10, 2026 - 09:52 UTC
Update - The first GhostLock KernelCare livepatches for the CloudLinux 9 / AlmaLinux 9 family are now in the testing feed and are expected to reach the main feed within hours. Once they promote to the main feed, subscribed CloudLinux 9 servers receive them automatically on the next update cycle. Livepatches for the remaining affected CloudLinux families are still in preparation. To update, you may run:
kcarectl --update --prefix test
Jul 10, 2026 - 04:02 UTC
kcarectl --update --prefix test
Jul 10, 2026 - 04:02 UTC
Monitoring - Patched kernels are available:
Patched CloudLinux kernels for CL7h and CL8 are in the beta/testing channel, and rollout to stable has started.
CL7h: kernel-4.18.0-553.141.2.lve.el7h or newer
CL8: kernel-4.18.0-553.141.2.lve.el8 or newer
AlmaLinux has published patched kernels to its testing repository.
CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-687.23.2.el9_8 or newer
CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-211.31.2.el10_2 or newer
Jul 09, 2026 - 12:11 UTC
Patched CloudLinux kernels for CL7h and CL8 are in the beta/testing channel, and rollout to stable has started.
CL7h: kernel-4.18.0-553.141.2.lve.el7h or newer
CL8: kernel-4.18.0-553.141.2.lve.el8 or newer
AlmaLinux has published patched kernels to its testing repository.
CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-687.23.2.el9_8 or newer
CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-211.31.2.el10_2 or newer
Jul 09, 2026 - 12:11 UTC
Update - GhostLock requires two fixes, shipped together: CVE-2026-43499 and CVE-2026-53166.
Both are required for a system to be considered patched.
All supported CloudLinux versions are affected — CL7, CL7h, CL8, CL8 LTS, CL9, CL9 LTS, CL10, and CloudLinux for Ubuntu 22.04 LTS. GhostLock's vulnerable range covers every kernel CloudLinux ships.
There is no practical runtime mitigation. The prerequisite CONFIG_FUTEX_PI is a build-time kernel option with no runtime switch, and it cannot be disabled on a running server without breaking the priority-inheritance mutexes applications depend on. There is no module to blacklist and no sysctl to set. Per-tenant sandboxing does not close it either - the trigger is the futex syscall, available to any local process. For containerized or sandboxed workloads only, a seccomp policy blocking FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI reduces exposure.
The kernel update or KernelCare livepatch is the fix.
Patched kernels and KernelCare livepatches for all affected versions are being prepared. A KernelCare livepatch will be available as a no-reboot alternative on every affected version. Target kernel versions and patch IDs will be posted here as each release ships.
Once KernelCare livepatches are live, verify both fixes are present:
kcarectl --patch-info | grep -E 'CVE-2026-43499|CVE-2026-53166'
Do not use kcarectl --info | grep CVE — it returns empty output even on correctly patched systems.
Full advisory and per-platform update instructions: GhostLock (CVE-2026-43499) blog post.
Jul 09, 2026 - 11:57 UTC
Both are required for a system to be considered patched.
All supported CloudLinux versions are affected — CL7, CL7h, CL8, CL8 LTS, CL9, CL9 LTS, CL10, and CloudLinux for Ubuntu 22.04 LTS. GhostLock's vulnerable range covers every kernel CloudLinux ships.
There is no practical runtime mitigation. The prerequisite CONFIG_FUTEX_PI is a build-time kernel option with no runtime switch, and it cannot be disabled on a running server without breaking the priority-inheritance mutexes applications depend on. There is no module to blacklist and no sysctl to set. Per-tenant sandboxing does not close it either - the trigger is the futex syscall, available to any local process. For containerized or sandboxed workloads only, a seccomp policy blocking FUTEX_LOCK_PI, FUTEX_WAIT_REQUEUE_PI and FUTEX_CMP_REQUEUE_PI reduces exposure.
The kernel update or KernelCare livepatch is the fix.
Patched kernels and KernelCare livepatches for all affected versions are being prepared. A KernelCare livepatch will be available as a no-reboot alternative on every affected version. Target kernel versions and patch IDs will be posted here as each release ships.
Once KernelCare livepatches are live, verify both fixes are present:
kcarectl --patch-info | grep -E 'CVE-2026-43499|CVE-2026-53166'
Do not use kcarectl --info | grep CVE — it returns empty output even on correctly patched systems.
Full advisory and per-platform update instructions: GhostLock (CVE-2026-43499) blog post.
Jul 09, 2026 - 11:57 UTC
Investigating - Patched kernels and KernelCare livepatches for affected CloudLinux versions are being prepared. For more details, please check: https://blog.cloudlinux.com/ghostlock-cve-2026-43499-local-root-exploit-kernel-update-for-cloudlinux/
Jul 08, 2026 - 18:40 UTC
Jul 08, 2026 - 18:40 UTC
Update - KernelCare live patches shipped for el8 + el9 kernels:
(RHEL/CentOS/Oracle/CloudLinux/Alma/Rocky, including cl8, cl7h and el9 FIPS/LTS)
el10, UEK R6/R7, and Amazon Linux 2/2023 still in progress.
Deploying the livepatch:
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
How to verify you are patched:
uname -r # fixed if: 5.14.0-687.26.1.el9_8+ / 4.18.0-553.144.1.el8_10+ / 6.12.0-211.34.1.el10_2+
kcarectl --info | grep kpatch-build-time # el8/el9 livepatch build dated 2026-07-16/17 or later
kcarectl --patch-info | grep -iE 'xfs|CVE-2026-64600' # silent releases carried no CVE ref at ship time
Jul 23, 2026 - 06:09 UTC
(RHEL/CentOS/Oracle/CloudLinux/Alma/Rocky, including cl8, cl7h and el9 FIPS/LTS)
el10, UEK R6/R7, and Amazon Linux 2/2023 still in progress.
Deploying the livepatch:
kcarectl --update --prefix test # from testing feed
kcarectl --update # once promoted to main
How to verify you are patched:
uname -r # fixed if: 5.14.0-687.26.1.el9_8+ / 4.18.0-553.144.1.el8_10+ / 6.12.0-211.34.1.el10_2+
kcarectl --info | grep kpatch-build-time # el8/el9 livepatch build dated 2026-07-16/17 or later
kcarectl --patch-info | grep -iE 'xfs|CVE-2026-64600' # silent releases carried no CVE ref at ship time
Jul 23, 2026 - 06:09 UTC
Monitoring - The patched CL8 kernel is available in our rollout repositories. Target version:
- CL8: kernel-4.18.0-553.144.1.lve.el8 or newer
To update, please run:
dnf update 'kernel*' --enablerepo=cloudlinux-rollout*
The patched CL9/CL10 are available in the stable repository. Target versions:
- CL9: kernel-5.14.0-687.26.1.el9_8 or newer
- CL10: kernel-6.12.0-211.34.1.el10_2 or newer
Jul 23, 2026 - 00:10 UTC
- CL8: kernel-4.18.0-553.144.1.lve.el8 or newer
To update, please run:
dnf update 'kernel*' --enablerepo=cloudlinux-rollout*
The patched CL9/CL10 are available in the stable repository. Target versions:
- CL9: kernel-5.14.0-687.26.1.el9_8 or newer
- CL10: kernel-6.12.0-211.34.1.el10_2 or newer
Jul 23, 2026 - 00:10 UTC
Investigating - RefluXFS (CVE-2026-64600), an XFS reflink direct-I/O race. A lock-drop window in the copy-on-write allocation path lets an unprivileged local user overwrite the on-disk contents of any file they can read (e.g.,/etc/passwd or a SUID-root binary) on any XFS with reflink=1 (the mkfs default since 2019, so the CloudLinux default). Result is full root.
CloudLinux 8, 9, and 10 are affected. The mitigation, patched kernel packages, and KernelCare live patch are currently in preparation. There is no fixed kernel to update to and no live patch in the feeds at this time.
Jul 22, 2026 - 19:06 UTC
CloudLinux 8, 9, and 10 are affected. The mitigation, patched kernel packages, and KernelCare live patch are currently in preparation. There is no fixed kernel to update to and no live patch in the feeds at this time.
Jul 22, 2026 - 19:06 UTC
About This Site
Welcome to CloudLinux status page. Here you can see if there are any ongoing issues with the CloudLinux network or other services.
CloudLinux OS Components
Operational
Alt-PHP
Operational
CageFS
Operational
MySQL Governor
Operational
EasyApache4 PHP packages
Operational
CloudLinux Kernel
Operational
Mod_lsapi
Operational
PHP Selector
Operational
Python Selector
Operational
Ruby Selector
Operational
Node.js Selector
Operational
CloudLinux Network
Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance