This guide is for existing WHM/cPanel servers still running Rocky Linux. It is intentionally different from the AlmaLinux and CloudLinux walkthroughs because cPanel’s current Rocky Linux documentation warns that new installs are no longer available and support status is not clean. Patch the emergency first, then plan a supported migration.
The immediate risks are the same: CVE-2026-41940 in cPanel/WHM and CVE-2026-31431 Copy Fail in the Linux kernel. The long-term risk is being stuck on a platform cPanel no longer wants you to build around.
Confirm What You Are Running
cat /etc/os-release
/usr/local/cpanel/cpanel -V
whmapi1 version
uname -r
df -h / /boot /usr/local/cpanel
If this is a customer-facing shared hosting node, announce a maintenance window. Kernel work requires a reboot unless you have a verified livepatch path from your vendor.
Step 1: Patch cPanel And WHM
Start with the cPanel layer. Rocky’s kernel update will not fix the cPanel authentication bypass.
/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard
If cPanel cannot update to a patched branch on this Rocky host, do not leave public WHM exposed while you figure it out. Use the mitigation commands below and prioritize migration.
Step 2: Patch The Rocky Linux Kernel
Rocky Linux has shipped Copy Fail patches for current Rocky lines. Update the kernel from trusted Rocky repositories, then reboot.
dnf clean metadata
dnf update kernel
dnf update
reboot
After reboot, verify the running kernel. If a third-party mirror is lagging, switch to a current Rocky mirror or your provider’s recommended repository and try again.
uname -r
rpm -q kernel
dnf updateinfo list --cve CVE-2026-31431 2>/dev/null || true
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --status
Step 3: Run The cPanel IOC Check
Use cPanel’s official CVE-2026-41940 detection script. Save the newest version from the advisory, review it, and run it as root.
vi /root/ioc_checksessions_files.sh
chmod 700 /root/ioc_checksessions_files.sh
bash /root/ioc_checksessions_files.sh --verbose
Emergency Mitigation If cPanel Will Not Patch
This is disruptive. Customers will lose access to cPanel/Webmail while services are stopped, but it closes the exposed control panel path while you build a supported server.
whmapi1 set_tweaksetting key=proxysubdomains value=0
/scripts/proxydomains remove
/scripts/rebuildhttpdconf
/scripts/restartsrv_httpd
whmapi1 configureservice service=cpsrvd enabled=0 monitored=0
whmapi1 configureservice service=cpdavd enabled=0 monitored=0
/scripts/restartsrv_cpsrvd --stop
/scripts/restartsrv_cpdavd --stop
Step 4: Plan The Migration
The clean path is to build a new supported WHM/cPanel server on AlmaLinux, CloudLinux, or Ubuntu 24.04, then transfer accounts with WHM’s Transfer Tool. For a small server, you can also make cPanel account packages manually.
# On the old Rocky server, list accounts:
/scripts/updateuserdomains
cat /etc/trueuserdomains
# Package one account if you need a manual move:
/scripts/pkgacct USERNAME
ls -lh /home/cpmove-USERNAME.tar.gz
For a production migration, lower DNS TTLs, build the new server, copy accounts, verify sites, mail, databases, cron, PHP versions, SSL, and DNS, then cut traffic over. Keep the old server online but locked down until customers confirm the move.
