CloudLinux Status

CIFSwitch (cifs.spnego LPE): Mitigation and Kernel Update on CloudLinux

Update - Patched CloudLinux kernels for CL7h and CL8 are released - available in the beta channel and rolling out to stable with an immediate-install bypass command.

Target versions:
- CL7h: kernel-4.18.0-553.126.2.lve.el7h or newer
- CL8: kernel-4.18.0-553.126.2.lve.el8 or newer

To install immediately without waiting for the gradual stable rollout:
yum update cloudlinux-release --enablerepo=cloudlinux-updates-testing
yum update --enablerepo=cloudlinux-rollout-4-bypass 'kernel*'
reboot

Patched LTS kernels are released to the beta channel.

Target versions:
- CL8 LTS: kernel-lts-5.14.0-284.1101.el8.tuxcare.11.els2 or newer
- CL9 LTS: kernel-lts-5.14.0-284.1101.el9.tuxcare.11.els2 or newer

Update with:
dnf update 'kernel-lts*' --enablerepo=cloudlinux-updates-testing
reboot
Jun 01, 2026 - 10:17 UTC

Update - KernelCare livepatches have been promoted to the main feed for CL7h, CL8, and CL9 (including the AlmaLinux 9.2 and 9.6 FIPS variants). KernelCare-subscribed servers running these versions receive the fix automatically on the next kcarectl --update.

Patches for CL10 and CloudLinux for Ubuntu 22.04 (Jammy) are now available in the testing feed. Apply immediately with kcarectl --update --prefix test
May 29, 2026 - 19:42 UTC

Update - Who is affected

Only hosts that have cifs-utils installed and permit unprivileged user namespaces:

- CloudLinux 7h, CloudLinux 8, CloudLinux 9, CloudLinux 10, CloudLinux for Ubuntu 22.04

CloudLinux 7 (CL7) is not affected in its stock configuration. No CVE has been assigned yet.

Mitigate now (either option breaks the chain):

- Option 1 - neutralize the cifs.spnego upcall, only if this host does not mount Kerberos-authenticated SMB shares:

echo "create cifs.spnego * * /bin/false" > /etc/request-key.d/cifs.spnego.conf

- Option 2 - disable unprivileged user namespaces.

Patched kernels

- CL9 / AlmaLinux 9: kernel-5.14.0-687.5.4.el9_8 or newer - available in the AlmaLinux testing repository.

- CL10 / AlmaLinux 10: kernel-6.12.0-211.7.4.el10_2 or newer - available in the AlmaLinux testing repository.

- CL7h / CL8: rebuilds on top of the AlmaLinux 8 fix are in build/test; target versions will follow.

Promotion to production repositories is pending community verification.

KernelCare livepatches (no reboot)

- EL8 family (CL7h, CL8): on the testing feed now; promotion to the main feed expected shortly.

- EL9: built and reviewed.

Install from the testing feed:

kcarectl --update --prefix test

Until a CVE is assigned, identify the patch by its description:

kcarectl --patch-info | grep cifs.spnego

Full and continuously updated details are in the blog post.
May 29, 2026 - 12:43 UTC

Update - Patched kernels for CL9/CL10 are available in the AlmaLinux testing repository. Target versions:

CL9 / AlmaLinux 9: kernel-5.14.0-687.5.4.el9_8 or newer
CL10 / AlmaLinux 10: kernel-6.12.0-211.7.4.el10_2 or newer

Promotion to production repositories is pending community verification. See the AlmaLinux advisory for upstream details.
May 29, 2026 - 03:57 UTC

Identified - CIFSwitch (cifs.spnego LPE) - mitigation available; patched kernels in build, KernelCare live patches rolling out.

More details in our blog: https://blog.cloudlinux.com/cifswitch-mitigation-and-kernel-update
May 28, 2026 - 18:23 UTC

Change in the CloudLinux repository access mechanism

Monitoring - We are making significant changes to the mechanism of accessing CloudLinux repositories.
This release affects Cloudlinux 8, 9 and Ubuntu. CL7 will be handled later. CL10 also receives an update though it already uses no-auth repos.
License validation has been moved within CloudLinux OS itself, so no action is required on the customer side other than updating the packages, which will be discussed below.

The transition on the client servers will be implemented by updating the cloudlinux-release and rhn-client-tools packages; therefore, if these packages are excluded from the update for any reason, please unblock them so you do not lose the ability to receive updates.
The version of the rhn package that will be updated is rhn-client-tools 3.0.3-1; versions of the cloudlinux-release packages depend on the system being used and can be found in our changelog:
CloudLinux 8 release packages
CloudLinux 9 release packages
CloudLinux 10 release packages
For Ubuntu it is - cloudlinux-release 0.1-10

Rollout of the packages will begin on April 30.

ELS repos brough by php-els, python-els, etc packages can be accessed via JWT token.
If you have questions about how access to ALT-ELS repositories works, you can find more details in this article:
alt-PHP, Python, NodeJS, Ruby repositories changes in CloudLinux 10

Important! If, for whatever reason, you are currently unable to update your packages and switch to the new mirrors, you will not be left without updates. There will be a transition period lasting several months during which both the old and new mirror systems will operate simultaneously.
Apr 29, 2026 - 09:19 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

Past Incidents

Jun 2, 2026

No incidents reported today.

Jun 1, 2026

Unresolved incident: CIFSwitch (cifs.spnego LPE): Mitigation and Kernel Update on CloudLinux.

May 31, 2026

No incidents reported.

May 30, 2026

No incidents reported.

May 29, 2026

May 28, 2026

May 27, 2026

Linux kernel ptrace exit-race information disclosure - ssh-keysign-pwn (CVE-2026-46333)

Resolved - This incident has been resolved.
May 27, 18:07 UTC

Monitoring - A fix has been implemented and we are monitoring the results.
May 22, 10:07 UTC

Identified - KernelCare:
CloudLinux 9 / AlmaLinux 9 livepatch is in the testing and main feeds now. Deploy with 'kcarectl --update'.
Please stay tuned to Linux Kernel ptrace Exit-race Vulnerability / ssh-keysign-pwn (CVE-2026-46333)
____
May 19, 20:49 UTC

Update - The AlmaLinux patched kernels have been promoted from testing to the production repositories.
Target versions remain:
kernel-5.14.0-611.54.6.el9_7 (CL9)
kernel-6.12.0-124.56.5.el10_1 (CL10)

To update:
dnf update 'kernel*'

More details are in our Blog
Linux Kernel ptrace Exit-race Vulnerability / ssh-keysign-pwn (CVE-2026-46333)
May 18, 05:18 UTC

Update - CloudLinux 7h and CloudLinux 8 patched kernels have been released to the beta channel. Target versions:

- CloudLinux 7h: kernel-4.18.0-553.124.4.lve.el7h
- CloudLinux 8: kernel-4.18.0-553.124.4.lve.el8

To update:

- CL7h: yum --enablerepo=cl7h_beta update 'kernel*'
- CL8: yum --enablerepo=cloudlinux-updates-testing update 'kernel*'

Then reboot. Promotion to the stable channel follows after beta validation.
May 15, 21:23 UTC

Update - AlmaLinux has published patched kernels to the testing repository (AlmaLinux advisory). Target versions:

CloudLinux 9 / AlmaLinux 9: kernel-5.14.0-611.54.6.el9_7
CloudLinux 10 / AlmaLinux 10: kernel-6.12.0-124.56.5.el10_1
Promotion to the production repositories is pending community verification.

More details are in our Blog
Linux Kernel ptrace Exit-race Vulnerability / ssh-keysign-pwn (CVE-2026-46333)
May 15, 15:28 UTC

Update - Clarification:

New status for CL7h and CL8 - this bug persists in the kernel, but is not yet exploitable with the current exploit.
May 15, 12:36 UTC

Investigating - Right after the kernel privilege-escalation chain in the XFRM/ESP subsystem (Copy Fail, Dirty Frag, Fragnesia), Qualys disclosed a different Linux kernel issue. This time in the ptrace access-check path. No official name or CVE has been assigned at the time of writing (the working name will be filled in once Qualys / NVD publish). A public proof-of-concept exists. An unprivileged local user on an affected host can use it to read root-owned secrets (SSH host private keys and the shadow password database) without obtaining root privileges directly.

Affected CloudLinux versions:

CloudLinux 7 (CL7) No
CloudLinux 7h (CL7h) No
CloudLinux 8 (CL8) No
CloudLinux 9 (CL9 ) Yes
CloudLinux 10 (CL10) Yes

There are three layers of mitigation, applicable independently or in combination:
1) The recommended quick win is the CloudLinux-specific sysctl kernel.user_ptrace=0 . It blocks the issue at the kernel level host-wide and is reversible with a single sysctl. Followed by CageFS (already protects caged tenants by default) and SUID strip as a tactical fallback

Note: with kernel.user_ptrace=0, unprivileged users can no longer attach gdb -p, strace -p, or perf trace --pid to their own processes. Monitoring agents that ptrace-attach without CAP_SYS_PTRACE will also break. On typical shared-hosting workloads this is acceptable; on developer or CI hosts, expect attach-debug to break for non-root users.

2) Already in place: CageFS protects caged tenant

3) Remove the SUID bit from chage and ssh-keysign

sudo chmod u-s /usr/libexec/openssh/ssh-keysign 2>/dev/null sudo chmod u-s /usr/bin/chage

For details, please refer:
Public proof-of-concept (ssh-keysign-pwn)
Upstream fix — commit 31e62c2ebbfd in Linus tree
CloudLinux blogpost with detailed mitigation and Kernel update on CloudLinux (pending)
May 15, 12:14 UTC

Fragnesia

Resolved - This incident has been resolved.
May 27, 18:05 UTC

Monitoring - A fix has been implemented and we are monitoring the results.
May 22, 10:08 UTC

Update - The KernelCare livepatch rollout is now complete on the main feed across all primary distributions: AlmaLinux ELS/FIPS variants, the EL8 family, Debian 11, Debian 12, and Ubuntu Jammy.
KernelCare-subscribed servers receive the fix automatically on the next 'kcarectl --update'
May 19, 20:39 UTC

Update - A new wave of KernelCare livepatches incorporating the additional upstream fix has been released to the testing feed. Affected distributions in this wave: EL8, EL9, Debian 12, and AlmaLinux 10.

To deploy from the testing feed:

kcarectl --update --prefix test

Livepatches incorporating the additional upstream fix are now promoted to the main feed. KernelCare-subscribed servers on the main feed receive the fix automatically on the next kcarectl --update.

Patch IDs released today:

K20260515_34 — Rocky Linux 10
K20260515_27 — Oracle Linux 9
K20260515_21 — Oracle Linux 8 (UEK 7)
K20260515_20 — Oracle Linux 9 (UEK 7)
K20260515_01 — Ubuntu Noble
K20260515_02 — Ubuntu Noble (AWS)
May 15, 14:48 UTC

Update - For customers running the LTS kernel, patched versions are released. Target versions:

kernel-lts-5.14.0-284.1101.el8.tuxcare.7.els33 or newer
kernel-lts-5.14.0-284.1101.el9.tuxcare.7.els33 or newer
Update with:

dnf update 'kernel-lts*' --enablerepo=cloudlinux-updates-testing
reboot

Final patched kernels for CL7h and CL8 are released. Target versions:

CL7h: kernel-4.18.0-553.124.3.lve.el7h or newer
CL8: kernel-4.18.0-553.124.3.lve.el8 or newer
Both are available in the beta channel and rolling out to stable. Because the stable rollout is gradual, use the following command if you want to install immediately:

yum update cloudlinux-release --enablerepo=cloudlinux-updates-testing
yum update --enablerepo=cloudlinux-rollout-7-bypass 'kernel*'
reboot
May 15, 12:54 UTC

Update - Imunify360 already blocks the exploit related to Fragnesia (CVE-2026-46300) and uses extended heuristics to identify and mitigate new indicators more quickly! It does not replace the kernel update, but customers running Imunify360 are covered against currently observed exploitation attempts. More info: https://imunify360.com/

Update: May 15

CloudLinux kernel (CL7h, CL8)
The AlmaLinux 8 fix that CloudLinux kernels for CL7h and CL8 build on has been rebuilt as kernel-4.18.0-553.124.3.el8_10 (now in AlmaLinux testing) to incorporate additional upstream patches. CloudLinux kernel builds are being updated accordingly. CL target package versions and channel availability will be added here on release.

AlmaLinux kernel (CL9, CL10)

The patched kernels in the AlmaLinux testing repository have been rebuilt to incorporate additional upstream patches. Updated target versions:
CL9 / AlmaLinux 9: kernel-5.14.0-611.54.5.el9_7 or newer
CL10 / AlmaLinux 10: kernel-6.12.0-124.56.3.el10_1 or newer
These supersede the prior test builds (5.14.0-611.54.4.el9_7 and 6.12.0-124.56.2.el10_1). If you installed the earlier test kernel, update and reboot again.
Promotion to production repositories will follow once community verification is complete.

KernelCare:
First KernelCare livepatches are released for CloudLinux 9 customers running ELS or FIPS variants of the AlmaLinux 9 kernel.
KernelCare-subscribed servers in scope receive the fix on the next 'kcarectl --update'.

We'll keep you posted!
More details are in our Blog https://blog.cloudlinux.com/fragnesia-mitigation-and-kernel-update
May 15, 12:20 UTC

Update - We are continuing to work on a fix for this issue.
May 15, 12:16 UTC

Identified - Fragnesia is a separate bug from Dirty Frag, not a re-announcement. It is, however, in the same XFRM/ESP class and the immediate mitigation is identical. Customers who have already applied the Dirty Frag mitigation need no further action until patched kernels are released.

Affected CloudLinux versions
CloudLinux 7 (CL7) No
CloudLinux 7h (CL7h) Yes
CloudLinux 8 (CL8) Yes
CloudLinux 9 (CL9 ) Yes
CloudLinux 10 (CL10) Yes

Apply this mitigation now
Until a patched kernel or KernelCare livepatch is installed, blacklist the esp4, esp6, and rxrpc modules so they cannot be loaded, and unload them if already present:
sudo sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"
If you already applied this exact mitigation for Dirty Frag, no further action is required. The file already exists and Fragnesia is blocked by the same rule.

We've published a blog post with a lot of up-to-date information on the issue:
Fragnesia — Mitigation and Kernel Update on CloudLinux
May 13, 15:31 UTC

Dirty Frag [CVE-2026-43284]

Resolved - This incident has been resolved.
May 27, 18:04 UTC

Monitoring - A fix has been implemented and we are monitoring the results.
May 22, 10:07 UTC

Update - "DirtyDecrypt" proof-of-concept clarification:

A new proof-of-concept named "DirtyDecrypt" is circulating in the press, including a Bleeping Computer write-up.

Our team has reviewed the PoC and confirmed it does not work against systems that have applied a patched kernel from any of the three streams below. Customers who are already patched require no additional action.
May 19, 20:44 UTC

Update - Patched kernels are available in the AlmaLinux stable repository. Target versions:
CL9 / AlmaLinux 9: kernel-5.14.0-611.54.3.el9_7 or newer
CL10 / AlmaLinux 10: kernel-6.12.0-124.55.2.el10_1 or newer

Patched kernels for CL7h and CL8 are now available in the beta channel. Target versions:
CL7h: kernel-4.18.0-553.123.2.lve.el7h or newer
CL8: kernel-4.18.0-553.123.2.lve.el8 or newer
May 8, 18:22 UTC

Update - KernelCare patches are actively deploying. Rollout is in progress for the following distros (signed versions included):

- RHEL 8
- CloudLinux 8
- CloudLinux 7 Hybrid
- Oracle Linux 8
- CentOS 8
- Rocky Linux 8
- AlmaLinux 8

These should reach the main feed within the next couple of hours. Further updates to follow.
May 8, 11:43 UTC

Identified - Please refer to the mitigation and kernel update steps published in the blog:
https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
May 8, 10:09 UTC

Update - We are continuing to investigate this issue.
May 7, 21:48 UTC

Investigating - Dirty Frag [CVE Pending] is a Linux kernel local privilege escalation in the xfrm subsystem. The flaw lives in the ESP-in-UDP MSG_SPLICE_PAGES no-COW fast path and is reachable via the XFRM user netlink interface, which auto-loads the relevant modules. A working public proof-of-concept exists; any unprivileged local user can use it to gain root in a single command.

Affected Components:
CloudLinux 7h, 8, 9, and 10.

Published blog:
https://blog.cloudlinux.com/dirty-frag-mitigation-and-kernel-update
May 7, 21:47 UTC

Copy Fail Vulnerability - CVE-2026-31431

Resolved - This incident has been resolved.
May 27, 18:02 UTC

Monitoring - A fix has been implemented and we are monitoring the results.
May 19, 20:51 UTC

Update - KernelCare live patches for CVE-2026-31431 ("CopyFail") have been released for the following operating systems:

almalinux8
almalinux9
almalinux10
alma9.6 esu
alma9.2 esu
cloudlinux7h
cloudlinux8
cloudlinux9
centos8
redhat8
redhat9
proxmox-ve-7-5.15
ubuntu-focal-lts-jammy-aws
ubuntu-focal-lts-jammy
ubuntu-focal-lts-jammy-azure
ubuntu-jammy-aws
ubuntu-jammy-azure
ubuntu-jammy
ubuntu-bionic-lts-focal
ubuntu-bionic-lts-focal-aws
ubuntu-focal-azure
ubuntu-focal-aws
ubuntu-focal
rockylinux8
rockylinux9
oraclelinux8
oraclelinux8-uek6
oraclelinux7-uek6
oraclelinux9
debian11
debian12
May 11, 18:47 UTC

Update - We have delivered KernelCare patches for several distributions. The available patches on the main feed at the moment are:
K20260501_02 (oel8-uek6)
K20260501_10 (rocky9)
K20260430_07 (alma9.6 esu)
K20260430_13 (alma9.2 esu)

Additionally, patches for these distributions are released on the test feed:
oel7-uek6
cl7h
cl8
oel8
centos8
rhel8
alma8
alma9
cl9
rhel9
pve-7-5.15
ubuntu-focal-lts-jammy-aws
ubuntu-focal-lts-jammy
ubuntu-focal-lts-jammy-azure
ubuntu-jammy-aws
ubuntu-jammy
ubuntu-jammy-azure

A key detail for the patches still on the test feed, is that you need to enable said feed while running the update command:
kcarectl --update --prefix test
May 1, 16:28 UTC

Update - Patched kernel has been released into testing repo:
for CloudLinux 8 - 4.18.0-553.121.1.lve.el8.x86_64
for CloudLinux 7h - 4.18.0-553.121.1.lve.el7h.x86_64

for CloudLinux 8:
yum update kernel --enablerepo=cloudlinux-updates-testing

for CloudLinux 7h:
yum update kernel --enablerepo=cl7h_beta
May 1, 09:09 UTC

Update - We are continuing to work on a fix for this issue.
May 1, 09:08 UTC

Identified - Patched kernel has been released into testing repo:
for CloudLinux 8 - 4.18.0-553.121.1.lve.el8.x86_64
for CloudLinux 7h - 4.18.0-553.121.1.lve.el7h.x86_64

yum update kernel --enablerepo=cloudlinux-updates-testing
May 1, 09:02 UTC

Update - We've published a blog post with a lot of up-to-date information on the issue
CVE-2026-31431 (Copy Fail): Mitigation and Upcoming Patches for CloudLinux
Apr 30, 16:54 UTC

Update - A temporary workaround has been found

It prevents the algif_aead_init() initialization function from being called during kernel boot.
Please note that applying this workaround requires a reboot!

What needs to be done:
grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
reboot
Apr 30, 16:35 UTC

Investigating - Copy Fail (CVE-2026-31431) is a Linux kernel bug in the crypto component authencesn. It allows a normal local user to make a very specific 4-byte change to the cached contents of any readable file on the system. In practice, that means a small Python script could tamper a setuid binary and gain root access on most major Linux distros shipped since 2017.

We're investigating the situation and a patch is on its way for CloudLinux kernels and KernelCare.
Apr 29, 21:34 UTC

May 26, 2026

No incidents reported.

May 25, 2026

No incidents reported.

May 24, 2026

No incidents reported.

May 23, 2026

No incidents reported.

May 22, 2026

Slow download rates from CloudLinux mirrors in the EU regions

Resolved - This incident has been resolved
May 22, 07:26 UTC

Monitoring - Infrastructure adjustments have been made, and we're keeping an eye on the situation
May 14, 05:42 UTC

Investigating - We are experiencing issues with download speed from mirrors in the EU region. It may cause slow download rates and timeouts during yum updates:

1. Repodata metadata returning 404:
Status code: 404 for https://rollout-ng.cloudlinux.com/slot-8/8/x86_64/repodata/-primary.xml.gz
Error: Failed to download metadata for repo 'cloudlinux-rollout-8'
2. Slow / timed-out RPM transfers:
Curl error (28): Timeout was reached for https://rollout-ng.cloudlinux.com/slot-1/10/x86_64/.rpm [Operation too slow. Less than 51200 bytes/sec transferred the last 30 seconds]

This issue is currently being investigated by our infrastructure team under task REAIT-564. Further updates will be shared as soon as progress is made.
May 13, 20:23 UTC

May 21, 2026

No incidents reported.

May 20, 2026

No incidents reported.

May 19, 2026