On April 28, 2026, cPanel disclosed CVE-2026-41940, a critical (CVSS 9.8) authentication bypass in cPanel & WHM that lets unauthenticated remote attackers gain root-level administrative access.

If you have any reason to believe a server you manage was compromised before you patched – unexpected sessions in /var/cpanel/sessions/raw/, unfamiliar logins in WHM, multiple hacked websites patching alone does not evict an attacker who already established persistence.

If you are not sure whether your server has been infected, you can run a detection script provided by cPanel here, however this does not rule out server infection.

It’s important to understand that once a server has been compromised, keeping it running is dangerous, even after a thorough check by a professional. Modern post-exploitation toolkits are designed specifically to survive cleanup: rootkits hide in kernel modules, persistence is split across multiple unrelated locations so removing one leaves the others intact, and tampered binaries can pass casual inspection. You can spend days cleaning up a server and still miss the one backdoor that matters.

You should migrate to a clean cpanel installation AS SOON AS POSSIBLE.

1. Reset the root password

If you still have a working SSH session as root, set a new password.

If you’ve been locked out, boot the server into your provider’s rescue / recovery environment, mount the root filesystem, and reset the password from there. Most providers (Hetzner, OVH, DigitalOcean, AWS via single-user mode). Once the password is reset, reboot back into the normal system before continuing.

2. Audit SSH keys for root user

When logged in as root in SSH, run:

cat /root/.ssh/authorized_keys

Anything you don’t personally recognize should be removed, no exceptions as attackers typically install a key as their first persistence step because it survives password resets.

3. Inspect cron for persistence

Cron is the second-favorite persistence mechanism. Check root’s crontab and every system cron location.

crontab -l # root’s user crontab

Check every

Then walk through each cron directory under /etc/:

ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/

/etc/cron.d/ — drop-in cron files. Probably the most abused location after a root compromise; attackers prefer it because new files here don’t disturb existing system crontabs.

/etc/cron.hourly/ — scripts run every hour.

/etc/cron.daily/ — scripts run once per day.

/etc/cron.weekly/ and /etc/cron.monthly/ — less commonly used, but check them anyway.

/etc/crontab — the system-wide crontab.

Pay attention to modification times. If anything in these directories was modified around or after 28 April, 2026 (and you didn’t touch it), open the file and read it. Common patterns to watch for: curl/wget piped into bash, base64-encoded payloads, calls out to a domain or IP you don’t recognize, and reverse-shell one-liners disguised as “maintenance” scripts.

Also check /var/spool/cron/ (the actual per-user crontab files that crontab -l displays) and /etc/anacrontab.

Finally, run a check for running processes with high CPU/Ram usage:

ps auxf --sort=-%cpu | head -40
ps auxf --sort=-%mem | head -30

Check all running processes and if you are unsure about a process look it up online

ps -ef --forest

4. Revoke WHM API tokens

In WHM, search for “Manage API Tokens”. List every token. Anything you didn’t issue, revoke. Anything you did issue but can’t remember why, revoke. Tokens grant API-level root and survive password resets — this is the third common persistence path.

5. Lock down SSH access

Edit /etc/ssh/sshd_config and append at the bottom:

AllowUsers root

You can list multiple users space-separated. This will make sure any users who might have been granted administrator privileges are unable to login.

If you have a separate user and then use sudo to get root privileges, you need to replace root with the username of the user you are using.

After changing sshd_config, restart the ssh service:

service ssh restart

Open another SSH session and try to login to make sure you still have access using SSH.

6. Audit sudoers

Run the following commands to see users on sudo or wheel group. Unless you have added a user to sudo group, the first command should have an empty result and the second command should just output an entry starting with wheel normally.

getent group sudo
getent group wheel

Then run:

cat /etc/sudoers

and look for any entries allowing users to run commands. Generally this file does not have normal entries but just comments. In the example below, the user “nikos123” can execute any command (similar to being root):

nikos123    ALL=(ALL)       NOPASSWD: ALL

If you did not add this user intentionally, you should comment it out.

Also, check folder /etc/sudoers.d – usually this should be empty.

7. Install CSF and close the cPanel/WHM ports

By filtering the service ports that provide administrative access into the server, you basically prevent anyone from logging in. Install Configserv Firewall using the command:

yum -y install cpanel-csf

Then edit /etc/csf/csf.conf and remove ports 2082-2096 from TCP_IN. Also remove port 22 (ssh). The full list of ports you want blocked from the public internet:

• 2082, 2083 – cPanel
• 2086, 2087 – WHM
• 2095, 2096 – Webmail
• 22 – SSH

Also, make sure at the top of the config file, TESTING setting is set to: 0

TESTING = “0”.

Whitelist your own administrative IPs so you don’t lock yourself out:

csf -a YOUR-IP

Restart the firewall for the rules to take effect.

csf -e; csf -r

The seven steps above evict the most common persistence and re-entry paths used after a CVE-2026-41940 compromise: stolen credentials, planted SSH keys, hidden cron jobs, leftover API tokens, sudoers backdoors, and an unfiltered control-plane port.

If you find indicators of an actual successful exploit, not just exposure you should treat the server as compromised and rebuild. Provision a clean machine, reinstall cPanel, restore accounts from a backup taken before the suspected compromise window , and decommission the old server. The cost of a rebuild is always lower than the cost of explaining to a customer why their data is on a leak site.