CloudLinux announced on 10 September 2026 that it is rotating the GPG key used to sign every package it ships. From 1 December 2026, CloudLinux 7, 8, and 9 packages are signed exclusively with the new key. Servers that don't already trust that key fail signature verification on the next yum update and stop receiving updates entirely — no CVE patches, no kernel builds, no package installs — until someone fixes it.
This isn't a security vulnerability and there's no CVE attached. It's routine key hygiene, the kind every package vendor does periodically. But it fails silently until the cutover date, which makes it the sort of thing that's easy to miss on a fleet you're not actively watching. If you manage more than a handful of CloudLinux boxes, this is a five-minute check per server now instead of an emergency later.
Who actually needs to act
Only servers running an outdated cloudlinux-release package are affected. If yours is already current, the new key is already in your trust store and 1 December changes nothing for you. The minimum versions that already ship the new key:
| Version | Minimum cloudlinux-release |
|---|---|
| CloudLinux 9 | 9.6-2 |
| CloudLinux 8 | 8.10-8 |
| CloudLinux 7 | 7.9-2.12 |
Anything older than these needs the update below before the switch date.
Check your version
rpm -q cloudlinux-release
Compare the output against the minimum versions in the table. If you manage a fleet, script the check rather than eyeballing each server — pssh or an Ansible ad-hoc command against your inventory beats logging into every box by hand:
ansible all -m command -a "rpm -q cloudlinux-release"
You can also confirm the new key is already trusted directly, which is the more reliable check if you're unsure cloudlinux-release version numbers map cleanly to key trust on your particular install history:
rpm -q gpg-pubkey --qf '%{SUMMARY}\n' | grep 'CloudLinux Extension Signer'
A hit means you're covered. No output means the new key isn't in the RPM trust database yet.
Update before 1 December
If your cloudlinux-release version is below the minimum, update it:
yum update cloudlinux-release
This pulls in the current release package, which carries the new signing key alongside your existing repo definitions. It doesn't touch anything else on the system — no kernel change, no reboot, no service restart. Re-run the verification command above afterward to confirm the key landed:
rpm -q gpg-pubkey --qf '%{SUMMARY}\n' | grep 'CloudLinux Extension Signer'
Where this fits with CageFS and LVE updates
CloudLinux's own packages — CageFS, LVE Manager, the hardened PHP builds — ship through the same repos and are signed with the same key rotation. If you're running CloudLinux's hardened PHP builds or rely on CageFS for tenant isolation, those update channels are covered by the same fix: update cloudlinux-release, and every CloudLinux-signed package on the box trusts the new key going forward. There's no separate key to import for CageFS or LVE specifically.
If you're also running KernelCare for live kernel patching, that's a separate signing chain through TuxCare's own infrastructure and isn't affected by this rotation — but it's worth checking kcarectl --patch-info at the same time you're doing this sweep, since you're already touching the server.
Fleet-wide rollout
For more than a few servers, don't wait for the deadline to push this out one at a time. A one-line cron entry or a pre-deploy Ansible task run against your whole CloudLinux inventory now removes the risk entirely:
yum update cloudlinux-release -y
Run it through whatever orchestration you already use for patch management — WHM's standardized hooks or a simple Ansible playbook both work, since the update itself carries no risk of service disruption. There's no reason to stagger this one across a maintenance window the way you would a kernel update.