Log into WHM after a while away and there it is: a red badge on "Security Advisor" with a dozen warnings you've never seen before. Most admins either panic and start clicking "fix" on everything, or ignore it entirely because half the wording looks like generic filler. Neither is the right move. Some of these warnings genuinely matter on a production server; a few are noise for a specific setup. Here's what the common ones actually mean and what to do about each.
What Security Advisor actually checks
Security Advisor is a built-in WHM tool that runs a set of checks against your server's configuration — kernel version, open ports, mod_security status, SSH settings, cPHulk brute-force protection, PHP settings, and a handful of third-party integrations like Imunify360 or CSF. You'll find it under WHM > Home > Security Center > Security Advisor. Each finding is rated Good, Info, Medium Risk, or High Risk, and clicking a finding usually expands into a one-line explanation. The problem is that "one line" often isn't enough context to know whether it's urgent.
The warnings you'll see most often
"The system is affected by CVE-XXXX-XXXXX in kernel"
What it means: your running kernel has a known vulnerability, and a newer kernel patches it. This shows up constantly on servers that haven't been rebooted in months, because kernel updates install but don't take effect until reboot.
Fix:
yum check-update kernel
yum update kernel -y
rebootSchedule the reboot for low-traffic hours and warn anyone on that box first — it's a real downtime event, usually 60-120 seconds. On AlmaLinux/Rocky with kernel-livepatch enabled you may be able to skip the reboot, but check uname -r against rpm -q kernel --last to confirm you're actually running the patched build either way.
"cPHulk Brute Force Protection is not enabled"
What it means: exactly what it says — nothing is rate-limiting or blocking repeated failed logins to cPanel, WHM, FTP, or email. Leave this off and you will eventually see thousands of login attempts a day in your Exim and cPanel logs.
Fix: WHM > Security Center > cPHulk Brute Force Protection > enable it. Set "Number of failures" around 5-6 before a temporary block, and enable "Trust hosts that provide valid SSH keys" so your own automation doesn't get locked out. This is one of the very few High Risk findings you should never leave unresolved on a public-facing server.
"Apache mod_security is not enabled"
What it means: the web application firewall that filters malicious request patterns (SQLi attempts, known exploit signatures, bad user agents) is off. WordPress sites especially rely on this as a first line of defense against automated exploit scanners.
Fix: WHM > Security Center > ModSecurity ™ Configuration > enable it, and enable the OWASP or Comodo rule set if one isn't active. One caveat: mod_security occasionally blocks legitimate WooCommerce checkout or Contact Form 7 submissions with a 403. If that happens after enabling it, don't disable mod_security wholesale — find the specific rule ID in /usr/local/apache/logs/error_log and disable just that rule for that domain.
"PHP open_basedir Protection is not enabled"
What it means: without open_basedir, a compromised script in one cPanel account can read or write files in other accounts on the same server. On shared or reseller hosting this is the difference between one hacked site and every site on the box getting hacked.
Fix: WHM > Service Configuration > PHP Configuration Editor, or via MultiPHP INI Editor per account. Turning it on can occasionally break a script that references an absolute path outside the account's home directory (rare, usually a badly written plugin) — if a site errors out after enabling it, check that script's file paths before assuming it's Security Advisor's fault.
"The system is not currently using SMTP restrictions"
What it means: any user on the server can send mail directly through port 25 without going through the account's authenticated mail queue. This is exactly how a single compromised WordPress install turns into your server's IP getting blacklisted for spam.
Fix: WHM > Service Configuration > SMTP Restrictions > enable it. Legitimate mail from PHP's mail() function or the cPanel mail queue still goes through fine; this only blocks scripts that try to open a raw socket straight to port 25.
"Two-Factor Authentication is not enabled for root"
What it means: root login to WHM only needs a password. If that password ever leaks — reused elsewhere, phished, brute-forced — there's nothing else standing between an attacker and full server control.
Fix: WHM > Security Center > Two-Factor Authentication, enable it for the account, then set it up with an authenticator app (Google Authenticator, Authy, etc.) before logging out. Keep the recovery codes somewhere outside the server itself — a password manager, not a text file in /root.
Findings you can usually leave for later
| Warning | Why it's lower priority |
|---|---|
| "Apache is not configured to redirect to the SSL vhost by default" | Cosmetic if you're already forcing HTTPS via .htaccess or Cloudflare at the edge |
| "Weak cipher suites are enabled" | Only matters if you're supporting very old clients; most modern configs already exclude the worst ciphers |
| "cPanel PHP is EOL" | Relevant if you actively use it, but many admins keep it installed for one legacy tool and run current PHP for everything else |
These aren't "ignore forever" — they're "schedule for your next maintenance window" rather than "drop what you're doing."
How to work through the list without breaking anything
- Sort by severity: clear every High Risk item first, then Medium.
- Change one setting at a time on a production box, not five at once — if something breaks, you'll know exactly which change did it.
- Check
/usr/local/apache/logs/error_logand your site's own error log for 15-20 minutes after each change, especially after enabling mod_security or open_basedir. - Re-run Security Advisor after each batch of fixes to confirm the finding actually cleared — some checks cache results until the next cron run.
Security Advisor is a checklist, not a guarantee. Clearing every warning on the page doesn't mean the server is unhackable — it means you've closed the obvious, well-known doors. Combine it with regular updates, backups you've actually tested a restore from, and a firewall like CSF or Imunify360 for anything it doesn't cover.
Frequently Asked Questions
Will fixing Security Advisor warnings slow down my server?
Not meaningfully. mod_security and open_basedir add a small amount of per-request overhead, but it's negligible next to typical PHP execution time. cPHulk and SMTP restrictions have essentially no performance cost at all.
Why does a warning keep reappearing after I fix it?
Security Advisor results are cached and refresh on a cron schedule, usually once every 12-24 hours. If you just made a change, give it time before assuming the fix didn't take — or trigger a manual re-check from the Security Advisor page itself.
Can I disable specific Security Advisor checks I don't care about?
WHM doesn't offer a per-check dismiss option in most versions — the list reflects live server state. If a finding genuinely doesn't apply to your setup (for example, weak cipher warnings when you terminate SSL at Cloudflare), just note it and move on rather than fighting the tool.
Is it safe to enable everything at once on a live production server?
It's safer to batch by risk level and test in between, as described above. mod_security in particular can produce false-positive 403s on legitimate form submissions, so it's worth watching logs closely right after turning it on rather than walking away.
Does SkyServer manage this for me on managed hosting plans?
On SkyServer's managed cPanel and VPS plans, our team reviews Security Advisor findings as part of routine server maintenance. If you're on an unmanaged VPS, open a support ticket and we can walk through the current findings with you.
