I Audited a Production WHM/cPanel Server. Here's What I Found (and How to Check Yours)

Ricardo Loureiro — Fri, 12 Jun 2026 12:02:37 +0000

Last month I ran a security audit on a production WHM/cPanel server. It belonged to a web agency hosting a couple dozen client sites — WordPress, WooCommerce, the usual stack.

The server had been running for years without anyone really looking at it. Sites were up, clients were happy, nobody touched anything. Sound familiar?

Here's what I found:

OpenSSH vulnerable to a critical CVE** (remote code execution class — the kind you patch the day it's announced, not years later)
SSH open to the world on port 22, root login enabled, password authentication on
No brute-force protection beyond cPHulk's defaults
PHP versions EOL'd long ago, still serving production sites
"Backups configured" — but never test-restored. Two were silently failing
No firewall rules beyond the defaults. Every service exposed

None of this is exotic. This is what most long-running cPanel servers look like when nobody owns them. So here's the audit checklist I use — run it on your own server this week. It takes about an hour.

1. Are you running vulnerable services?

The single highest-impact check. Start with SSH, since it's the front door:

ssh -V

Compare against the OpenSSH release notes and check the version against known CVEs. If you're on a years-old version, assume it's vulnerable.

On AlmaLinux/CloudLinux/RHEL-family (which is what cPanel runs on), check what security updates are pending:

yum updateinfo list security all

If that list is long, that's your priority for the week. Don't cherry-pick — patch.

2. Harden SSH (15 minutes, massive payoff)

Edit /etc/ssh/sshd_config:

# Move off the default port (reduces noise, not a security measure by itself)
Port 2222

# No root over SSH. Ever. Use a sudo user.
PermitRootLogin no

# Keys only. Passwords get brute-forced.
PasswordAuthentication no
PubkeyAuthentication yes

# Limit who can even try
AllowUsers youradminuser

Then restart: systemctl restart sshd — but test the new connection in a second terminal before closing your current session. Locking yourself out of a production server is a rite of passage you can skip.

Better yet: restrict SSH access to your IP at the firewall level, so the rest of the internet can't even reach the port.

3. Install and actually configure a firewall

cPanel servers should be running CSF/LFD (ConfigServer Security & Firewall). It's free and integrates directly into WHM:

cd /usr/src
wget https://download.configserver.com/csf.tgz
tar -xzf csf.tgz
cd csf && sh install.sh

The defaults are decent, but the minimum to configure:

TESTING = "0" once you've confirmed you're not locked out
Close every port you don't use. A typical cPanel server needs far fewer open ports than the default
Enable LFD login failure detection for SSH, FTP, mail, and cPanel itself
Set LF_PERMBLOCK = "1" for repeat offenders

4. Audit your PHP versions

Run this in WHM → MultiPHP Manager, or from the shell:

whmapi1 php_get_installed_versions

Anything EOL (check php.net/supported-versions) is unpatched attack surface — and on a shared server, one compromised site is a problem for every site. Move accounts off EOL versions. If a client's site "needs" PHP 7.4 in 2026, that's a conversation about updating the site, not a reason to keep the server vulnerable.

5. Test a backup restore. Today.

A backup you've never restored is a hope, not a backup.

Whatever you use — cPanel's native backups, JetBackup, rsync scripts — do this:

Pick one account
Restore it to a test location (JetBackup can restore to an alternate account)
Verify: files there? Database imports? Emails intact?

The agency server I audited had backups "running" for months. Two accounts were silently failing on a database dump error. Nobody knew, because nobody had ever restored one.

While you're at it, check the 3-2-1 basics: are backups stored off the server? A backup on the same disk as production protects you from nothing that matters.

6. Check who can do what

# Who has shell access?
grep -v '/sbin/nologin\|/bin/false' /etc/passwd

# Who's in the wheel/sudo group?
grep wheel /etc/group

# Any resellers with root-level WHM privileges they don't need?

In WHM → Edit Reseller Nameservers and Privileges, audit reseller ACLs. "All features" granted years ago for convenience is privilege escalation waiting to happen.

7. The quiet ones people skip

Symlink protection — enable it in WHM (EasyApache → Apache symlink protection) so one compromised account can't read other accounts' files
ModSecurity — should be on, with the OWASP CRS or Comodo ruleset
cPHulk — enabled, with country-level blocking if your users are geographically predictable
Disable unused services — systemctl list-units --type=service --state=running and ask yourself why each one is there
/tmp mounted with noexec,nosuid — classic and still effective

The real takeaway

None of these steps are hard. The problem is never the difficulty — it's that nobody owns the server. Sites get built, deployed, and forgotten. The server hums along until the day it doesn't, and that day is expensive: downtime, blacklisted IPs, compromised client data, weekend recovery marathons.

If you're a developer or agency running your own WHM/cPanel box: block one hour, run this checklist, and write down what you find. Worst case, you confirm you're in good shape. Best case, you find the thing before someone else does.

I've spent 15+ years managing Linux and WHM/cPanel infrastructure, and these days I help web agencies keep their client-hosting servers secure and online through SysBalance. Questions about anything in this checklist? Drop them in the comments — happy to go deeper on any of these.

DEV Community: Ricardo Loureiro