dnf update aborts on CL9 + EPEL: ea-php81-85-php-gd and alt-php GD require libavif.so.15, EPEL 9 libavif 1.1.1 clashes with alt-common libavif/svt-av1-libs
Update - We are continuing to investigate this issue.
Sep 29, 2026 - 16:28 UTC
Investigating - On CL9 cPanel servers with EPEL enabled (default best=True), `dnf update` / upcp aborts completely:
"package ea-php8X-php-gd ... requires libavif.so.15()(64bit), but none of the providers can be installed".

To let updates proceed, add this line to the [epel] section of /etc/yum.repos.d/epel.repo and run your update again:
excludepkgs=libavif* svt-av1*

This is a temporary workaround. Remove the exclude once the fix (ALTPHP-2626) is released. A regular dnf update will then complete normally.
Sep 29, 2026 - 15:33 UTC
bridge-stp-uaf (CVE-2026-72389)
Update - The patched CloudLinux 7h and CloudLinux 8 kernels have moved out of beta. A staged rollout to the stable channel began on September 23, 2026, so servers on the stable channel pick the update up progressively rather than all at once. Target versions are unchanged: kernel-4.18.0-553.157.1.lve.2.el8 and kernel-4.18.0-553.157.1.lve.2.el7h.

To install now rather than wait for the rollout to reach your server, use the beta-channel commands below and reboot. Once the rollout completes, the standard yum update 'kernel*' followed by a reboot is enough.
Sep 24, 2026 - 20:00 UTC
Update - KernelCare livepatches for CloudLinux 7h and CloudLinux 8 are on the main feed. The CloudLinux 7h patch covers the kernel 4.18.0-553.157.1.lve.2.el7h. Subscribed servers take them on their next update cycle.
Sep 23, 2026 - 19:42 UTC
Update - Status summary as of September 23, 2026

CloudLinux 7:
Patch under assessment. Not exposed to ordinary accounts by default.

CloudLinux 7h and CloudLinux 8 (exposed by default):
Fixed kernel 4.18.0-553.157.1.lve.2 is in the beta channel; KernelCare livepatch is on the testing feed kcarectl --update --prefix test.
Stable/main-feed release will follow the normal schedule.

CloudLinux 8 LTS (exposed by default):
Patched kernel in preparation. KernelCare does not cover this kernel line. Keep the modprobe mitigation in place until the fixed kernel ships.

CloudLinux 9:
KernelCare livepatch on the main feed kernel 5.14.0-687.46.1.el9_8.
Not exposed to ordinary accounts by default.

CloudLinux 9 LTS:
Patch in preparation. Not exposed to ordinary accounts by default.

CloudLinux 10: KernelCare livepatch on the main feed kernel 6.12.0-211.53.1.el10_2.
Not exposed to ordinary accounts by default.

Verify a KernelCare-patched server with:
kcarectl --patch-info | grep CVE-2026-72389

Full details and mitigation instructions: https://blog.cloudlinux.com/bridge-stp-uaf-cve-2026-72389-kernel-update-cloudlinux
Sep 22, 2026 - 23:05 UTC
Update - KernelCare livepatches for CloudLinux 7h and CloudLinux 8 have reached the testing feed. The CloudLinux 7h patch covers kernel 4.18.0-553.157.1.lve.2.el7h. Servers on the default feed do not have these yet; to take one from the testing feed now:
kcarectl --update --prefix test
Sep 22, 2026 - 23:05 UTC
Update - The KernelCare livepatch for CloudLinux 10 is on the main feed and covers the CloudLinux 10 kernel 6.12.0-211.53.1.el10_2. Subscribed servers take it on their next update cycle. Livepatches for CloudLinux 7h and CloudLinux 8 are still in preparation.
Sep 19, 2026 - 04:00 UTC
Update - The KernelCare livepatch for CloudLinux 9 is now on the main feed, covering kernel 5.14.0-687.46.1.el9_8. Subscribed servers receive it automatically on the next update cycle, or immediately with kcarectl --update; verify with kcarectl --patch-info | grep CVE-2026-72389.
Sep 15, 2026 - 23:51 UTC
Identified - bridge-stp-uaf (CVE-2026-72389, CVSS 7.0, Moderate per Red Hat) is a vulnerability in the Linux kernel’s bridge Spanning Tree Protocol timers. A local unprivileged user who can configure a network bridge can turn it into root on the host. The researchers published helper code rather than a working exploit, and none has appeared publicly since.

Affected: → Affected CloudLinux versions
CloudLinux 7h, CloudLinux 8 and CloudLinux 8 LTS, where an ordinary hosting account reaches the flaw as shipped.
The vulnerable code is in every CloudLinux kernel, but CloudLinux 7, 9, 9 LTS, 10 and CloudLinux for Ubuntu 22.04 are not exposed to ordinary accounts by default.

Mitigation: one modprobe rule that stops the bridge module from loading. No reboot on hosts that do not bridge. → Is there a mitigation?

Fix status → Update instructions
CloudLinux 7h and 8 kernel: patched kernels 4.18.0-553.157.1.lve.2 are in the beta channel; promotion to stable follows on the normal schedule. → Stream 1
AlmaLinux kernel (CloudLinux 9, 10): no fixed kernel yet. Red Hat lists its kernels as affected with no fix published, and AlmaLinux follows Red Hat. Both versions are not exposed by default. → Stream 2
CloudLinux 8 LTS and 9 LTS kernel (TuxCare ELS): in preparation. → Stream 3
KernelCare livepatch: in preparation. → Stream 4

Verify: uname -r against the target version in your stream; kcarectl –patch-info | grep CVE-2026-72389 once a livepatch ships. → How to verify you are patched

Why it matters: on a shared host the local user is whoever compromised one of your sites, and root on the kernel is root over every tenant. → Why this matters on a shared host

How the bug works: a topology-change timer can be armed on a bridge that is already down, and deleting the bridge frees it with the timer still queued. → Technical details of the bug
Sep 10, 2026 - 17:53 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

Oct 1, 2026

No incidents reported today.

Sep 30, 2026

No incidents reported.

Sep 29, 2026

CloudLinux/KernelCare Patch For Januscape (CVE-2026-53359)
Resolved - This incident has been resolved.
Sep 29, 12:24 UTC
Update - Patched kernels are available for all affected platforms:

- CloudLinux 7h / 8: kernel-4.18.0-553.139.3.lve.el7h / kernel-4.18.0-553.139.3.lve.el8 or newer, in the stable channel — yum update 'kernel*' and reboot; testing-channel steps are no longer needed
- CloudLinux 9 / 10: in the AlmaLinux production repositories (kernel-5.14.0-687.23.1.el9_8, kernel-6.12.0-211.31.1.el10_2 or newer) — dnf update kernel and reboot
- CloudLinux 8 LTS / 9 LTS: patched kernel-lts in the TuxCare ELS stable repository — yum update kernel-lts and reboot

KernelCare livepatches are on the main feed for CloudLinux 8, 9, 10, and CloudLinux for Ubuntu 22.04, and in the testing feed for CloudLinux 7h.
Sep 3, 20:02 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, 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, 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, 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, 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 7, 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).

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 7, 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 7, 15:05 UTC

Sep 28, 2026

No incidents reported.

Sep 27, 2026

No incidents reported.

Sep 26, 2026

CVE-2026-64600 (RefluXFS)
Resolved - Fixed kernels are available for all affected CloudLinux platforms:

- CloudLinux 7 Hybrid: kernel-4.18.0-553.144.1.lve.el7h or newer
- CloudLinux 8: kernel-4.18.0-553.144.1.lve.el8 or newer
- CloudLinux 9: kernel-5.14.0-687.26.1.el9_8 or newer (via AlmaLinux)
- CloudLinux 10: kernel-6.12.0-211.34.1.el10_2 or newer (via AlmaLinux)
- CloudLinux 8 LTS / 9 LTS (TuxCare ELS): kernel-lts-5.14.0-284.1101.{el8,el9_2}.tuxcare.11.els9 or newer
Update with dnf update 'kernel*' (LTS: yum update kernel-lts) then reboot.

KernelCare livepatches are on the main feed for CloudLinux 8, 9 and 10. CloudLinux 6/7 are not affected; CloudLinux for Ubuntu 22.04 is not affected unless an XFS reflink filesystem is mounted.
Sep 26, 03:59 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, 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, 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, 19:06 UTC
Linux qdisc-rtab-race (CVE-2026-68138): qdisc rate-table UAF to local root
Resolved - Fixed kernels are available for the affected, exposed platforms:

- CloudLinux 8 and CloudLinux 7 Hybrid: kernel-4.18.0-553.150.1.lve.1 or newer — yum update 'kernel*' then reboot.
- CloudLinux 8 LTS and CloudLinux 9 LTS: kernel-lts-5.14.0-284.1101.{el8,el9}.tuxcare.11.els12 via TuxCare ELS — yum update kernel-lts then reboot.

CloudLinux 9 and CloudLinux 10 are not affected in practice: Red Hat has marked its 9 and 10 kernels "Will not fix", AlmaLinux tracks Red Hat, and ordinary accounts are not exposed in the default configuration.

Verify with uname -r. Full details in the blog post.
Sep 26, 03:24 UTC
Update - After further analysis, we've determined that this issue will not be addressed via KernelCare for EL8 through EL10. Our assessment found that the vulnerability cannot be practically promoted to a local privilege escalation (LPE) on these distributions, meaning the exploitability demonstrated on other platforms does not translate into a working attack path here.
Aug 27, 12:03 UTC
Identified -
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, 10:50 UTC

Sep 25, 2026

No incidents reported.

Sep 24, 2026

After updating to WordPress 7.1.0 AccelerateWP enabled websites with CloudFlare CDN plugin crashed
Resolved - The fixed package version is 1.9-38 or later:

rpm -qa | grep accelerate-wp
Sep 24, 23:45 UTC
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, 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, 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, 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, 07:33 UTC
VsockDrop (CVE-2026-53365) reaches Root with no Hypervisor and no privileges
Resolved - For operators running an exposed Ubuntu system, KernelCare has published a live patch for the 6.8 HWE kernel. It reached the main feed on 14 September 2026

This incident has been resolved
Sep 24, 19:47 UTC
Identified -
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, 06:30 UTC
BadGarbage (CVE-2026-53361) Local Root and Container Escape
Resolved - The patched kernel kernel-6.12.0-211.47.1.el10_2 is available in the stable repository.
The KernelCare livepatch for CVE-2026-53361 has shipped to the main feed.

This incident has been resolved
Sep 24, 19:39 UTC
Identified -
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, 22:03 UTC
GhostLock (CVE-2026-43499) Local Root Exploit
Resolved - This incident has been resolved.
Sep 24, 19:19 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, 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, 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, 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, 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, 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, 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, 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, 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, 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 9, 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 9, 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 8, 18:40 UTC

Sep 23, 2026

Sep 22, 2026

Zapscape (CVE-2026-64561) KVM guest escape and local root
Resolved - This incident has been resolved.
Sep 22, 23:12 UTC
Monitoring - Patched kernels are in the stable/production repositories for all platforms.
Sep 8, 23:43 UTC
Update - The patched kernel-lts package for ELS platforms is in the TuxCare ELS beta channel and rolling out to the stable channel:
- CloudLinux 8 LTS: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els10 or newer
- CloudLinux 9 LTS: kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els10 or newer (uname -r reports 5.14.0-284.1101.el9_2.tuxcare.11.els10)
Install with yum update kernel-lts and reboot. CloudLinux 8 LTS and 9 LTS receive the Zapscape fix through this package, not as a separate KernelCare livepatch.

KernelCare livepatches for Zapscape are in the main feed for CloudLinux 7h, CloudLinux 8, CloudLinux 9, CloudLinux 10, and CloudLinux for Ubuntu 22.04. Subscribed servers receive the patch automatically on the next update cycle, or immediately with kcarectl --update.
Sep 5, 03:19 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, 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, 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, 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, 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, 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, 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, 15:19 UTC
Nexus repository migration (nexus.repo.tuxcare.com)
Resolved - The migration of nexus.repo.tuxcare.com to the new infrastructure has been completed, and the service has been operating normally since September 20.
Sep 22, 22:57 UTC
Update - The migration has been completed, and Nexus is operating on the new infrastructure now.
Sep 20, 16:58 UTC
Monitoring - We are migrating our Nexus repository at https://nexus.repo.tuxcare.com/ to AWS.

The service is expected to remain available throughout, but brief interruptions are possible. If you cannot reach the repository during this window, please retry shortly.

Migration is expected to complete by approximately 03:00 CET on 19 September. We will keep this notice open until Tuesday 22 September while we confirm everything is operating normally.
Sep 18, 19:21 UTC

Sep 21, 2026

No incidents reported.

Sep 20, 2026

Sep 19, 2026

Sep 18, 2026

Sep 17, 2026

No incidents reported.

Incident History Powered by Atlassian Statuspage