cPanel Security Advisor Warnings: What to Fix, What to Skip
You open WHM, click Security Center > Security Advisor, and you're staring at a wall of red and yellow warnings. Some sound terrifying ("Apache should not run as root"), some sound like gibberish ("mod_ruid2 is not installed"), and none of them tell you which ones actually put your server at risk today. Here's a practical read of the report: what each common warning means, what to fix right now, and what's genuinely fine to leave on a normal shared or managed cPanel server.
Where to Find It
In WHM, it's under Home > Security Center > Security Advisor (root/admin access only). If you're on a shared hosting account without WHM access, cPanel has a smaller version of the same idea under cPanel > Security > Security Advisor — it only shows account-level items like Two-Factor Authentication and API tokens, not server-wide settings.
Every item gets a severity color: red (Important), yellow (Medium), grey/blue (Informational). WHM re-runs the checks automatically every so often, but you can force a fresh scan any time with the "Run All Checks" button at the top of the page.
Fix These Now
| Warning | What It Means | Fix |
|---|---|---|
| cPHulk Brute Force Protection is disabled | Nothing is rate-limiting failed logins to WHM, cPanel, or webmail. | WHM > Security Center > cPHulk Brute Force Protection > enable it, set failure threshold around 5-10. |
| PHP open_basedir Protection is disabled | A compromised script on one cPanel account can read files belonging to other accounts on the same server. | WHM > Service Configuration > PHP Configuration Editor, or MultiPHP INI Editor, and enable it per PHP version. |
| Your system's package manager has updates available | OS security patches are sitting unapplied. | SSH in and run dnf update (AlmaLinux/Rocky) or apt update && apt upgrade (Ubuntu). Schedule it via cron or unattended-upgrades so it doesn't pile up again. |
| The system is not configured to use SFTP with jailed/restricted access, or shell access is enabled for accounts that don't need it | Every cPanel user with shell access is a bigger attack surface if their password or key leaks. | WHM > Manage Shell Access > set to "jailed shell" or "disabled" for accounts that only need FTP/file manager. |
| Two-Factor Authentication is not enabled for your account | A leaked password alone gets someone into WHM or cPanel. | WHM/cPanel > Security > Two-Factor Authentication > set up with Google Authenticator or Authy, then require it for all accounts under Manage 2FA. |
If you're not comfortable running the PHP or OS changes yourself, this is exactly the kind of ticket to hand to your host — on Getwebup-managed VPS and cPanel plans, our support team can flip these for you without you needing root access.
Understand Before You Touch
"Apache should not run user scripts as the nobody user" / suEXEC and suPHP warnings
This is about whether PHP scripts run as the actual cPanel account owner or as a shared, low-privilege "nobody" user. Running as "nobody" means one hacked WordPress site can potentially read or write files in every other account on the box, since file permissions can't tell accounts apart. On CloudLinux servers (most modern cPanel hosts, including Getwebup's shared and reseller plans) this is handled automatically by CageFS and mod_lsapi/mod_ruid2, so the warning usually clears itself once CloudLinux is properly licensed and running — check WHM > CloudLinux > Configuration rather than trying to hand-fix Apache.
"Your system is not using the CloudLinux kernel"
Not every server runs CloudLinux (it's a paid add-on layered on CentOS/AlmaLinux). If you're on a plain AlmaLinux or Ubuntu VPS by choice, this warning is expected and not a bug — it's informational, not a vulnerability. It only matters if you were specifically sold CloudLinux resource isolation and it isn't actually active.
"Compilers are accessible to non-root users"
A compiler (gcc, cc) lets an attacker who's already gotten shell access build custom exploit binaries instead of relying on interpreted scripts. On a server with real shell users (developers, agencies) this matters. On a typical shared box where nobody has shell access at all, it's low priority — fix the shell-access warning first and this one often becomes moot.
"The mod_security module is not enabled" or "ModSecurity rule updates are not configured"
ModSecurity is the web application firewall that blocks common exploit patterns (SQLi, XSS payloads, known bad user agents) before they hit PHP. Worth enabling under WHM > Security Center > ModSecurity Configuration, but go in expecting some false positives — a plugin doing something unusual can get blocked with a 403. If that happens, don't disable ModSecurity entirely; find the rule ID in /usr/local/apache/logs/error_log and add a targeted exception for just that rule on that domain.
"PHP is running an End-of-Life version"
Different from the OS package warning above — this is about the PHP version itself (5.6, 7.2, 7.4 are all EOL now and no longer receive security patches even if fully "updated"). Check current versions in WHM > MultiPHP Manager. Before bumping the default, audit which sites are still pinned to an old version — jumping straight to the newest PHP can break older WordPress themes and plugins that haven't been updated in years.
What's Usually Fine to Leave Alone
- "The 'Compilers Restricted' feature is not restricting compilers for X account" — informational, low impact if the account has no shell access anyway.
- "cPanel & WHM version is not the latest release" if you're one point release behind (not multiple major versions) — cPanel ships frequent point releases and being a build or two behind on a stable tier isn't an emergency; just don't ignore it for months.
- SSL/TLS protocol warnings for services you don't actually use — for example an outdated cipher suite warning for FTP when the account only uses SFTP. Confirm the service is disabled rather than "fixing" a setting for something nobody connects to.
The rule of thumb: red items that involve authentication (2FA, cPHulk, shell access) or cross-account isolation (open_basedir, suEXEC) get fixed first. Informational/grey items about services or components you don't actually run can wait.
Prevention
- Put a recurring reminder on the calendar — monthly is enough — to open Security Advisor and clear anything new. New cPanel versions add new checks over time, so a clean report today doesn't stay clean forever.
- Enable cPHulk and 2FA once, for every account, and they stay fixed; they're the two warnings most worth never seeing again.
- Turn on automatic OS security updates (
dnf-automaticorunattended-upgrades) so the package-manager warning doesn't reappear every few weeks. - If you manage multiple cPanel accounts or resell hosting, run Security Advisor right after any bulk account migration — restored accounts sometimes come back with shell access or 2FA settings that don't match your current policy.
Frequently asked questions
Is it safe to ignore Security Advisor warnings entirely?
No, but not every warning needs action today. Red warnings tied to authentication (2FA, cPHulk) or account isolation (open_basedir, shell access) should be fixed right away. Grey/informational items about services you don't run can wait.
Why does Security Advisor show different warnings on my cPanel account than in WHM?
WHM's Security Advisor checks server-wide settings and needs root access. The cPanel-level Security Advisor is a smaller version that only shows account-specific items like Two-Factor Authentication and API tokens, since a regular hosting account can't change server config.
I enabled everything Security Advisor recommended and now a plugin is broken. What happened?
Usually it's ModSecurity blocking a legitimate request that matched a rule pattern, or open_basedir blocking a script that reads files outside its own account directory. Check the Apache error log for a ModSecurity rule ID, or the PHP error log for an open_basedir violation, and add a narrow exception rather than turning the protection back off.
Does fixing these warnings slow down my server?
Not meaningfully. ModSecurity and open_basedir add a small amount of per-request overhead, but it's negligible compared to the cost of a compromised account. cPHulk and 2FA have no performance impact at all — they only affect login attempts.
How often does cPanel add new Security Advisor checks?
Fairly often — new checks have shipped with major cPanel & WHM version updates for years. A report that was fully green last quarter can show new warnings after an update, which is exactly why it's worth a quick monthly check rather than a one-time fix.