Harden Shared cPanel Server: Secure CageFS and ModSecurity Setup

On a shared server every account is a potential entry point, and the 2026 CVE series showed how quickly a compromised customer account becomes a root problem. Three layers keep a single bad site from taking the whole box: filesystem isolation (CageFS), request filtering at the web server (ModSecurity), and detection of what gets through (Imunify or ClamAV). Each layer catches things the others miss, and none of them is a substitute for keeping cPanel and the kernel patched.

Short answer: Install CageFS on CloudLinux and enable it for every account so users cannot see each other’s files, deploy ModSecurity with the OWASP Core Rule Set through EasyApache 4 starting in DetectionOnly and moving to blocking once false positives are excluded per domain, and add Imunify360, ImunifyAV or ClamAV to catch what gets through. Keep cPanel auto-updates on and apply the 2026 kernel mitigations so none of the layers can be escaped.

Isolate accounts with CageFS

CageFS is a CloudLinux feature, so this section applies to CloudLinux 8, 9 or 10. On plain AlmaLinux you get partial isolation from cPanel’s jailshell and mod_ruid2/mod_suexec, but not the virtualised filesystem that stops one user from reading /etc/passwd, /proc entries for other users, or another account’s world-readable wp-config.php.

Install and enable it for all users:

yum install cagefs -y
/usr/sbin/cagefsctl --init
/usr/sbin/cagefsctl --enable-all

After that, every new account is caged automatically. Check with cagefsctl --list-enabled. Pair it with PHP Selector (lvemanager) so users run PHP inside the cage, and with LVE limits so a runaway site is throttled rather than starving its neighbours.

Two pitfalls: cron jobs and shell scripts that expect access to system paths outside the skeleton will break, and you must run cagefsctl --force-update after installing new system packages that users need (ImageMagick, a new PHP module) so the skeleton picks them up. When a customer reports “command not found” for something that clearly exists, the cage is usually the reason.

Deploy ModSecurity with the OWASP Core Rule Set

cPanel ships ModSecurity through EasyApache 4 as ea-modsec2-rules-owasp-crs (or the ModSecurity 3 connector on newer profiles). Install it from WHM » Software » EasyApache 4, or from the shell:

dnf install ea-modsec2-rules-owasp-crs -y
/scripts/restartsrv_httpd

Then enable the vendor under WHM » Security Center » ModSecurity Vendors and confirm the rule set is loaded. Start in detection-only mode for a week so you can see what would be blocked without breaking customer sites:

whmapi1 modsec_set_setting setting_id=1 state=DetectionOnly

Review hits under WHM » Security Center » ModSecurity Tools » Hits List. The rules that fire most on legitimate traffic are typically the request-body and SQL-injection anomalies triggered by WordPress page builders and WooCommerce checkouts. Disable individual rules per domain rather than globally: ModSecurity Tools » Rules List » Disable with a domain scope writes the exclusion to the vhost include, not to the global config.

Once the false-positive rate is acceptable, switch to blocking:

whmapi1 modsec_set_setting setting_id=1 state=On

If you run LiteSpeed Enterprise, the same rules load through its ModSecurity-compatible engine; check the LiteSpeed cPanel plugin version is at least 2.4.8 to be clear of CVE-2026-48172.

Choose a scanner: Imunify360, ImunifyAV or ClamAV

The scanning layer detects what the WAF let through: webshells uploaded through a vulnerable plugin, injected JavaScript, and cron-based persistence. There are three realistic options.

• Imunify360 is the full product: WAF with a WordPress-specific rule set enabled by default since August 2026, proactive defence for PHP, an L7 rate limiter, and the “Under Attack Mode” WebShield feature. It costs per server but folds the WAF and IDS work into one agent, and on CloudLinux it integrates with CageFS and LVE. Install with the vendor script after adding your licence key, then check imunify360-agent rstatus.
• ImunifyAV is the scanner-only product. The free tier detects; the paid ImunifyAV+ tier cleans. It is the sensible choice on AlmaLinux without CloudLinux where you already have ModSecurity and the cPanel CSF fork.
• ClamAV ships as a cPanel plugin (WHM » cPanel » Manage Plugins » ClamAV Scanner). Its default signatures are weak for PHP malware, so add a community webshell signature set and schedule scans yourself. It is free and better than nothing, but do not rely on it alone.

Whatever you pick, schedule a full scan of /home weekly and an on-access or inotify scan of upload directories if the product supports it. Make sure the scanner runs inside the LVE limits or outside business hours; a full-disk scan on a busy server at noon is a self-inflicted outage.

Close the remaining gaps

Hardening the web layer is pointless if mail or the kernel is the weak point. Alongside the three layers above:

• Keep cPanel auto-updates on and confirm the build each Monday with whmapi1 version.
• Apply the 2026 kernel mitigations or run KernelCare so Copy Fail and Dirty Frag cannot be used to escape CageFS.
• Disable the CSF Messenger service and remote URLGET lists if you run any CSF fork older than 16.31.
• Restrict outbound SMTP for the nobody user and set per-domain hourly mail limits, so a compromised site cannot become a spam source; our outbound spam guide covers the hunt when it happens anyway.
• Turn off symlink protection bypasses: make sure WHM » Tweak Settings » Enable EXPERIMENTAL Jailshell is not the only barrier and that Apache is built with the symlink-protection patch selected in EasyApache.

Verify

Test each layer on a throwaway account. Create a file outside the account’s home from a caged shell and confirm it fails. Send a request containing an obvious payload such as ?id=1' UNION SELECT to a site on the server and confirm a 403 with a matching entry in /etc/apache2/logs/modsec_audit.log. Upload the EICAR test string to public_html and confirm the scanner flags it within the scan interval. Run our server security audit script afterwards and keep its output as the baseline you compare against next quarter.

Harden shared cPanel server at a glance

Official documentation: Imunify360 documentation, CloudLinux documentation, OWASP CRS documentation.

Related guides: Fix Imunify360 missing from the WHM interface (enable-plugin and other causes) · Fix WordPress “cURL error 28: Failed to connect” caused by Imunify360 or CSF · Whitelist IPs and countries in Imunify360 from the CLI.

Frequently asked questions