CloudLinux Site Isolation: The Complete Guide for WHM/cPanel Hosting Providers and Server Administrators — Secure Shared Hosting, Prevent Cross-Account Contamination, and Harden Multi-Tenant Linux Servers

---

Introduction: The Shared Hosting Security Problem CloudLinux Site Isolation Solves

Shared hosting has always carried an inherent security tension: dozens, hundreds, or even thousands of websites share the same physical server resources — CPU, RAM, disk I/O, and critically, the same underlying Linux filesystem. For years, the nightmare scenario for hosting providers was cross-account contamination: one compromised website spreading malware to neighboring accounts, a hacked WordPress installation silently infecting every other site on the same server, or a malicious script reading files it has no business accessing.

Traditional shared hosting environments, even with cPanel and WHM, struggled with this problem at the filesystem level. Even with individual cPanel user accounts, a PHP process running under Apache’s shared user (nobody or www-data) could — under the right (or wrong) conditions — read files belonging to other accounts. The symlink attack became particularly notorious: a malicious script would create a symbolic link pointing to another account’s wp-config.php or .htpasswd, extract database credentials, and the breach would propagate silently.

CloudLinux OS, the enterprise Linux distribution purpose-built for shared hosting providers, addresses this problem at the kernel level through its flagship feature: Site Isolation (also referred to in documentation as CageFS + Symlink Protection + SecureLinks). This feature creates a true, hermetically sealed environment for each hosting account — a virtualized, jailed filesystem where no account can see, read, write to, or affect any other account’s files, processes, or resources.

This comprehensive guide covers everything WHM/cPanel server administrators and hosting providers need to know about CloudLinux Site Isolation: how it works at a technical level, how to enable and configure it, how it integrates with cPanel/WHM, what it protects against, and how to troubleshoot common issues.

---

What Is CloudLinux OS and Why Does Shared Hosting Need It?

CloudLinux OS is a commercial enterprise Linux distribution developed by CloudLinux Inc. (the same company behind Imunify360, KernelCare, and Imunify Email). It is built on top of the Red Hat Enterprise Linux (RHEL) / CentOS source base and extends the Linux kernel with hosting-specific security and resource management features.

CloudLinux is installed on an estimated 40%+ of all shared hosting servers globally, making it the dominant OS choice for hosting providers running cPanel/WHM. Its key feature set includes:

• LVE (Lightweight Virtual Environment) — Per-account CPU, memory, I/O, and process limits
• CageFS — Virtualized, per-user filesystem (the foundation of Site Isolation)
• MySQL Governor — Per-user database resource throttling
• PHP Selector — Per-user PHP version switching
• Node.js Selector, Python Selector, Ruby Selector
• Hardened PHP — PHP compiled with extra security patches
• SecureLinks — Kernel-level symlink and hardlink attack prevention
• Site Isolation — The full stack combining CageFS + SecureLinks into a unified protection layer

Site Isolation is not a single feature but a layered security architecture built on top of all these components working in concert.

---

Understanding the Threat Landscape: What Site Isolation Protects Against

Before diving into the technical implementation, it’s essential to understand the specific attack vectors that CloudLinux Site Isolation is designed to prevent.

1. Symlink Attacks (Symlink Race Attacks)

The most historically significant threat to shared hosting environments. In a symlink attack:

• A malicious or compromised PHP script creates a symbolic link (via PHP’s symlink() function or shell access) pointing to a sensitive file on another account — for example, /home/victim/public_html/wp-config.php
• Apache or PHP follows the symlink and serves the target file’s contents
• The attacker reads database credentials, secret keys, or any other sensitive configuration data
• The attack can be executed without ever having direct write access to the victim’s directory

CloudLinux’s SecureLinks feature patches the Linux kernel to prevent users from following symbolic links that they don’t own, blocking this entire class of attack at the OS level.

2. Hardlink Attacks

Similar to symlink attacks but using hard links rather than symbolic links:

• An attacker creates a hard link to a sensitive file in a world-readable location
• Even if the original file’s permissions are tightened later, the hard link retains access
• The attacker can read the file contents through the hard link indefinitely

CloudLinux’s SecureLinks also blocks unprivileged users from creating hard links to files they do not own.

3. Cross-Account File Reading (Information Disclosure)

On a standard Linux server without CloudLinux, a PHP script running as the Apache user (nobody or www-data) may be able to traverse the filesystem and read world-readable files in other accounts’ home directories. This includes:

• WordPress wp-config.php files (database passwords, secret keys)
• .env files (API keys, service credentials)
• Email configuration files
• Custom application configuration files
• Log files containing sensitive data

CageFS eliminates this entirely by giving each user account a virtualized view of the filesystem where other users’ home directories simply do not exist.

4. Process Snooping

Without isolation, a PHP script can read /proc/ filesystem entries and potentially enumerate other running processes, read their environment variables, or access their memory maps — all of which may expose sensitive runtime data.

CageFS provides each user with a private /proc namespace, so they can only see their own processes.

5. PHP Session Poisoning / Shared Session Attacks

In unprotected shared hosting, PHP session files may be stored in a shared temporary directory (/tmp). A script with access to /tmp can read or modify another account’s session files — potentially hijacking authenticated sessions.

CageFS gives each user a private /tmp directory, making shared /tmp session attacks impossible.

6. Shared Memory Attacks

Shared memory segments (/dev/shm, shm_open) in unprotected environments can potentially be read or written by multiple users. CageFS isolates shared memory on a per-user basis.

7. Malware Lateral Movement

When one website on a shared server is compromised by malware, the attacker’s goal is often lateral movement — spreading to other accounts to maximize impact, harvest more credentials, or use additional resources. Site Isolation creates hard boundaries that prevent malware from propagating between accounts even after a successful compromise.

---

CloudLinux CageFS: The Technical Foundation of Site Isolation

CageFS is the core technology underpinning CloudLinux Site Isolation. Understanding how it works is essential for any server administrator deploying and managing it.

What CageFS Does

CageFS creates a per-user virtualized filesystem — essentially a lightweight container or jail for each hosting account. Each user gets their own private view of:

• /etc — Sanitized system configuration (no /etc/shadow, no other users’ data)
• /tmp — Completely private temporary directory
• /proc — Private process namespace (only their own processes visible)
• /dev — Limited, safe device access
• /var — Selective access to only necessary variable data
• System binaries and libraries — Read-only copies or bind mounts of necessary tools

Critically, each user’s CageFS environment does not include:

• Other users’ home directories
• Sensitive system files (/etc/shadow, /etc/passwd full entries for other users)
• Server configuration files (/etc/my.cnf full contents, /etc/httpd/conf internals)
• Other processes’ /proc entries
• Shared /tmp files belonging to other users

How CageFS Works at the Kernel Level

CageFS uses Linux bind mounts and namespace isolation to construct each user’s private filesystem view. When a PHP process runs under a caged user:

1. The kernel’s mount namespace is modified for that process’s user context
2. A virtual root filesystem is assembled from a combination of shared read-only mounts (system binaries) and private writable mounts (user’s home, private /tmp)
3. The process can only traverse directories that exist in its constructed namespace
4. Attempts to access paths outside the cage return ENOENT (No such file or directory) or EACCES (Permission denied)

This is fundamentally different from traditional Unix permissions (chmod/chown), which can be bypassed through misconfiguration or race conditions. CageFS operates at the namespace level — the paths simply don’t exist from the caged process’s perspective.

CageFS Skeleton Directory

The CageFS skeleton is located at /usr/share/cagefs-skeleton/ and defines the baseline filesystem template for all users. It contains:

• Copies or symlinks of essential binaries (/bin, /usr/bin)
• Sanitized configuration files
• Required library files
• PHP interpreter and extensions

The skeleton is shared (read-only) across all users to minimize disk space usage. Per-user private directories are overlaid on top of the skeleton.

---

SecureLinks: Kernel-Level Symlink and Hardlink Protection

While CageFS handles filesystem namespace isolation, SecureLinks is CloudLinux’s kernel patch that specifically addresses symlink and hardlink attack vectors.

How SecureLinks Works

SecureLinks modifies the Linux VFS (Virtual Filesystem Switch) layer to enforce two critical rules:

Rule 1 — Symlink Ownership Check: When a process attempts to follow a symbolic link, the kernel checks whether the symlink’s owner matches the process’s effective user ID (or root). If the symlink is owned by a different user, the kernel refuses to follow it and returns EACCES. This makes symlink attacks impossible regardless of filesystem permissions.

Rule 2 — Hardlink Ownership Check: When a process attempts to create a hard link to an existing file, the kernel verifies that the process owns the target file. Unprivileged users cannot create hard links to files they do not own, even if those files are world-readable.

SecureLinks Configuration

SecureLinks behavior is controlled via /proc/sys/fs/ kernel parameters:

# Check current SecureLinks status
cat /proc/sys/fs/protected_symlinks
cat /proc/sys/fs/protected_hardlinks

On CloudLinux with Site Isolation enabled, both should return 1 (enabled). These settings can also be enforced persistently via /etc/sysctl.conf:

fs.protected_symlinks = 1
fs.protected_hardlinks = 1

Note: While modern Linux kernels (3.6+) include similar protections via protected_symlinks and protected_hardlinks sysctl parameters, CloudLinux’s implementation predates and goes further than the upstream kernel implementation, with additional checks specific to multi-tenant web hosting environments.

---

Site Isolation in the Context of cPanel and WHM

CloudLinux Site Isolation integrates seamlessly with cPanel and WHM, the dominant hosting control panel stack. The integration is deep and bidirectional: cPanel user account creation automatically provisions CageFS environments, and WHM provides administrative controls for managing isolation settings.

How cPanel Integration Works

When CageFS is installed and enabled on a CloudLinux + cPanel server:

1. New cPanel accounts automatically get a CageFS environment provisioned during account creation
2. Existing accounts can be batch-enrolled via the command line or WHM interface
3. PHP execution via Apache (mod_php, suPHP, PHP-FPM) runs inside the user’s cage
4. SSH/shell access for cPanel users with shell enabled is also caged
5. Cron jobs run inside the cage
6. CGI scripts run inside the cage

The cPanel user never notices any difference in their day-to-day operations — their files are accessible, PHP runs normally, emails work — but the underlying security architecture has changed fundamentally.

WHM Interface for Site Isolation / CageFS

In WHM (WebHost Manager), CageFS management is available under:

WHM → Plugins → CageFS

(Depending on WHM version and CloudLinux plugin version, it may also appear under WHM → Security Center → CageFS User Manager)

From the WHM CageFS interface, administrators can:

• Enable/disable CageFS globally
• Enable/disable CageFS per individual cPanel user (useful for users who need shell access without restrictions)
• View CageFS enrollment status for all accounts
• Manage skeleton updates
• Configure per-user exceptions

---

How to Enable CloudLinux Site Isolation on a cPanel/WHM Server

Prerequisites

Before enabling Site Isolation, ensure:

• The server is running CloudLinux OS (not CentOS, AlmaLinux, or other distros without CloudLinux kernel)
• CloudLinux kernel is active: uname -r should show lve in the kernel version string
• cPanel/WHM is installed and operational
• You have root SSH access

Step 1: Verify CloudLinux Is Running

# Check CloudLinux kernel
uname -r
# Expected output contains: lve (e.g., 3.10.0-1160.108.1.lve1.5.el7.x86_64)

# Check CloudLinux version
cat /etc/cloudlinux-release

Step 2: Install CageFS

# Install CageFS package
yum install cagefs

# Initialize CageFS (creates skeleton directory)
/usr/sbin/cagefsctl --init

The --init command:

• Creates the CageFS skeleton at /usr/share/cagefs-skeleton/
• Sets up necessary mount points
• Configures initial filesystem templates

This command may take several minutes on the first run as it builds the skeleton.

Step 3: Enable CageFS for All Users

# Enable CageFS for all existing cPanel users at once
/usr/sbin/cagefsctl --enable-all

Alternatively, enable for a specific user only:

/usr/sbin/cagefsctl --enable username

Or disable for a specific user (e.g., a developer who needs full shell access):

/usr/sbin/cagefsctl --disable username

Step 4: Verify CageFS Status

# Check status of all users
/usr/sbin/cagefsctl --list-enabled

# Check status of a specific user
/usr/sbin/cagefsctl --display-user-mode username

# Check overall CageFS status
/usr/sbin/cagefsctl --check

Step 5: Enable SecureLinks

# Check current SecureLinks status (both should be 1)
sysctl fs.protected_symlinks
sysctl fs.protected_hardlinks

# Enable if not already active
sysctl -w fs.protected_symlinks=1
sysctl -w fs.protected_hardlinks=1

# Make permanent across reboots
echo "fs.protected_symlinks = 1" >> /etc/sysctl.conf
echo "fs.protected_hardlinks = 1" >> /etc/sysctl.conf

Step 6: Update the CageFS Skeleton

# Update CageFS skeleton after any system updates
/usr/sbin/cagefsctl --update

This should also be run after:

• Installing new PHP versions via cPanel EasyApache
• Updating CloudLinux packages
• Installing new system software that PHP scripts might need access to

---

Configuring PHP Handlers for Maximum Site Isolation

Site Isolation is most effective when PHP runs in a way that respects per-user identity. The PHP handler choice has significant implications for isolation effectiveness.

PHP Handler Comparison for Site Isolation

PHP Handler	User Context	CageFS Compatible	Isolation Level
mod_php (DSO)	Apache user (nobody)	Limited	Low
suPHP	cPanel user	Yes	High
suEXEC + CGI	cPanel user	Yes	High
PHP-FPM (per-user pool)	cPanel user	Yes	Highest
PHP-FPM (nobody pool)	Apache user	Limited	Low

Recommended: PHP-FPM with per-user pools (also called “PHP-FPM with suEXEC”) provides the highest level of isolation. Each cPanel user’s PHP processes run under their own UID/GID, which means:

• CageFS is properly applied per user
• File operations are correctly attributed to the owning user
• Malware from one account cannot impersonate another account’s user identity

To configure PHP-FPM per-user pools in WHM:

WHM → Service Configuration → Configure PHP-FPM → Enable PHP-FPM

Then for each domain or globally:

WHM → MultiPHP Manager → Set handler to PHP-FPM

---

CloudLinux Site Isolation and WordPress: Specific Considerations

WordPress is by far the most common application on shared hosting servers, and it is also the most common malware target. Understanding how Site Isolation interacts with WordPress is essential.

WordPress File Permissions Under CageFS

With CageFS and proper PHP-FPM per-user pools enabled, WordPress files should be owned by the cPanel user account:

# Correct ownership
ls -la /home/username/public_html/wp-config.php
# Should show: -rw-r--r-- 1 username username

WordPress Automatic Updates Under CageFS

WordPress core auto-updates, plugin updates via wp-admin, and file-write operations continue to work normally under CageFS because PHP runs as the cPanel user who owns the files. No special configuration is needed.

WP-CLI Under CageFS

WP-CLI (WordPress Command Line Interface) works correctly under CageFS when run as the cPanel user:

# Run as the cPanel user via su
su - username -c "wp plugin update --all"

# Or using the cagefs-entered shell
/bin/cagefs_enter.proxied username wp plugin update --all

WordPress Malware Containment

With Site Isolation active, if a WordPress site on account user_a is compromised by malware:

• The malware can only write to files owned by user_a
• It cannot read user_b‘s wp-config.php or other credentials
• It cannot create symlinks that expose other accounts’ files
• Lateral movement to other accounts is blocked at the kernel level
• The compromise is contained to user_a‘s account

This is transformative for hosting providers managing hundreds or thousands of WordPress sites — a single compromise no longer triggers a server-wide incident.

---

Managing CageFS: Advanced Configuration and Administration

The /etc/cagefs/ Configuration Directory

CageFS’s main configuration lives in /etc/cagefs/:

/etc/cagefs/
├── cagefs.mp          # Mount points configuration
├── users.enabled      # Explicitly enabled users
├── users.disabled     # Explicitly disabled users
├── users.mp           # Per-user mount overrides
├── exclude/           # Files/dirs excluded from cage (accessible to all users)
└── conf.d/            # Additional configuration fragments

Customizing the CageFS Skeleton

If your users need access to a binary or library that isn’t included in the default skeleton:

# Add a binary to the skeleton
/usr/sbin/cagefsctl --addrpm package_name

# Manually add a file to the skeleton
echo "/usr/bin/mybinary" >> /etc/cagefs/conf.d/custom.cfg
/usr/sbin/cagefsctl --update

Per-User Mount Points

Some applications require access to specific system paths. You can configure per-user mount exceptions:

# Edit per-user mounts
vi /etc/cagefs/users.mp

Format:

%username
/path/to/mount

Checking CageFS Logs

CageFS logs are available at:

# Main CageFS log
tail -f /var/log/cagefs.log

# Check for cage entry failures
grep "DENY" /var/log/cagefs.log

Entering a User’s Cage for Debugging

As root, you can enter a user’s CageFS environment to test and debug:

/bin/cagefs_enter.proxied username

This drops you into the user’s caged shell, allowing you to see exactly what that user’s environment looks like — which files are visible, which commands are available, and what the effective filesystem namespace contains.

---

Site Isolation and PHP Selector

CloudLinux’s PHP Selector integrates with CageFS to allow per-user PHP version management without compromising isolation:

• Each cPanel user can select their own PHP version (PHP 7.4, 8.0, 8.1, 8.2, 8.3, etc.) via cPanel
• The selected PHP binary is mounted into the user’s CageFS environment
• PHP extensions can be enabled/disabled per user without affecting other users
• The isolation boundary is maintained regardless of which PHP version the user runs

Enabling PHP Selector in WHM

# Install CloudLinux PHP Selector
yum install alt-php* cagefs

# Enable PHP Selector
/usr/bin/cloudlinux-selector install --interpreter=php

Then in WHM: WHM → Feature Manager → Enable PHP Selector for the desired feature lists.

---

Imunify360 + CloudLinux Site Isolation: The Complete Security Stack

CloudLinux Site Isolation and Imunify360 are complementary security layers that work together to provide defense-in-depth for shared hosting environments:

Layer	Technology	Function
Filesystem Isolation	CageFS	Namespace separation, private /tmp, /proc
Link Attack Prevention	SecureLinks	Blocks symlink/hardlink attacks
Malware Detection	Imunify360 Scanner	Detects infected files
Real-Time Protection	Imunify360 Proactive Defense	Blocks malicious PHP execution
Web Application Firewall	Imunify360 WAF (ModSecurity)	HTTP-level attack filtering
Intrusion Prevention	Imunify360 IDS/IPS	Network-level threat blocking
Resource Control	LVE (CloudLinux)	Prevents resource abuse/DoS

When both CloudLinux Site Isolation and Imunify360 are deployed:

• A compromised account is isolated (CageFS — can’t reach other accounts)
• The malware is detected (Imunify360 scanner)
• Malicious PHP execution is blocked in real time (Imunify360 Proactive Defense)
• The WAF filters the attack vector before it can execute
• Resources are capped so the compromised account can’t DoS the server (LVE)

This is the gold standard security stack for shared WordPress hosting.

---

Troubleshooting Common CloudLinux Site Isolation Issues

Issue 1: PHP Scripts Cannot Write to Files They Should Own

Symptoms: WordPress plugin/theme updates fail, image uploads fail, file permission errors in error logs.

Cause: PHP is running as Apache’s user (nobody) rather than the cPanel account user, meaning it’s caged under a different context.

Solution: Switch to PHP-FPM with per-user pools:

# In WHM: MultiPHP Manager → Change handler to PHP-FPM
# Or via CLI:
whmapi1 php_set_vhost_versions version=ea-php81 vhost=domain.com

Issue 2: Specific Command/Binary Not Available Inside Cage

Symptoms: Shell scripts or cron jobs that call system binaries fail with “command not found.”

Solution:

# Find which package provides the binary
rpm -qf /usr/bin/mybinary

# Add it to CageFS
/usr/sbin/cagefsctl --addrpm package_name
/usr/sbin/cagefsctl --update

Issue 3: WP-CLI or Composer Fails in CageFS

Symptoms: WP-CLI commands fail when run via SSH as the cPanel user.

Solution: Ensure the cPanel user’s shell is set correctly and WP-CLI is accessible inside the cage:

# Add WP-CLI to CageFS
echo "/usr/local/bin/wp" >> /etc/cagefs/conf.d/custom.cfg
/usr/sbin/cagefsctl --update

Issue 4: Cron Jobs Not Running Under CageFS

Symptoms: Cron jobs work outside CageFS but fail when CageFS is enabled.

Solution: cPanel cron jobs run inside the cage by default. If a cron job requires access to a path not in the cage:

# Add the required path to the skeleton
echo "/path/to/required/resource" >> /etc/cagefs/conf.d/cronjobs.cfg
/usr/sbin/cagefsctl --update

Issue 5: SSL Certificate Issues Inside CageFS

Symptoms: PHP curl calls fail with SSL certificate verification errors inside CageFS.

Solution: Ensure the CA certificates bundle is accessible inside the cage:

/usr/sbin/cagefsctl --addrpm ca-certificates
/usr/sbin/cagefsctl --update

Issue 6: MySQL Connection Failing Under CageFS

Symptoms: PHP cannot connect to MySQL via socket (/var/lib/mysql/mysql.sock) inside CageFS.

Solution: The MySQL socket path needs to be mounted inside the cage:

# Add MySQL socket to CageFS mount points
echo "/var/lib/mysql/mysql.sock" >> /etc/cagefs/cagefs.mp
/usr/sbin/cagefsctl --remount-all

---

Performance Impact of CloudLinux Site Isolation

A common question from hosting providers evaluating CloudLinux Site Isolation is: does CageFS affect server performance?

The honest answer is: minimally, and the security benefits far outweigh the cost.

Measured Performance Characteristics

• Filesystem overhead: CageFS uses bind mounts and namespace isolation. The overhead per filesystem operation is negligible (microseconds) because no data is copied — mounts are virtual
• Process startup overhead: Each new PHP-FPM process or CGI execution involves setting up the mount namespace, adding approximately 1–5ms of startup time — imperceptible to end users
• Memory overhead: Each user’s CageFS environment requires a small amount of kernel memory for mount namespace tracking, typically 1–4KB per active user
• I/O overhead: Zero — CageFS does not add a layer of I/O buffering or interception for file reads/writes within the cage

Performance vs. Security Trade-Off

The minimal performance cost of CageFS is justified by what it prevents: a single account compromise cascading into a server-wide incident that requires emergency response, data breach notifications, client churn, and reputational damage — all of which have costs orders of magnitude greater than CageFS’s performance overhead.

---

CloudLinux Site Isolation vs. Docker/LXC Containers vs. VPS

It’s useful to understand how CloudLinux Site Isolation compares to other isolation approaches:

Feature	CloudLinux CageFS	Docker Container	VPS/VM
Isolation Level	Per-user filesystem namespace	Full container namespace	Full OS isolation
Setup Overhead	Minimal	Moderate	High
Per-account cost	Very low	Low-moderate	High
cPanel integration	Native	None	Via WHM
PHP Selector support	Yes	Manual	Manual
Suitable for shared hosting	Yes	No	No
Resource overhead	~1–5ms process startup	Moderate	High
Symlink protection	Kernel-level	N/A (single tenant)	N/A

CloudLinux CageFS occupies a unique niche: it delivers meaningful isolation comparable to containerization but at the density and cost structure of shared hosting. This is why it has become the standard for hosting providers rather than running each account in a separate Docker container or VPS.

---

Enabling Site Isolation via WHM: Step-by-Step Visual Guide

For administrators who prefer the WHM graphical interface over command-line management:

Accessing CageFS in WHM

1. Log into WHM as root (https://yourserver.com:2087)
2. In the left navigation, search for “CageFS” or navigate to Plugins → CageFS
3. The CageFS User Manager dashboard loads, showing enrollment status for all accounts

Enabling CageFS for All Users

1. On the CageFS dashboard, click “Enable All” to enroll all existing cPanel accounts
2. A progress indicator shows enrollment status
3. New accounts are automatically enrolled going forward

Enabling/Disabling for Individual Accounts

1. On the CageFS dashboard, locate the user in the list
2. Toggle the Enabled/Disabled switch next to their username
3. Changes take effect immediately — no service restart required

Verifying the Status

The WHM CageFS dashboard shows a color-coded status for each user:

• Green / Enabled: User is caged and protected
• Red / Disabled: User is outside CageFS (intentional bypass)
• Gray / Skipped: User is a system account, not applicable

---

Best Practices for Deploying CloudLinux Site Isolation in Production

For New Server Deployments

• Install CloudLinux OS from the start (or convert from CentOS/AlmaLinux using the CloudLinux conversion script)
• Enable CageFS during initial server setup, before any accounts are created
• Configure PHP-FPM with per-user pools as the default PHP handler in EasyApache 4
• Enable SecureLinks via sysctl at OS configuration time
• Pair with Imunify360 for full defense-in-depth

For Existing Servers with Live Accounts

• Enable CageFS during a maintenance window if possible
• Test with a small number of non-critical accounts first
• Monitor error logs closely for the first 24–48 hours after enabling
• Have a rollback plan: cagefsctl --disable-all can quickly revert if critical issues arise
• Communicate proactively with customers about the security enhancement

Ongoing Maintenance

• Run cagefsctl --update after every major system update, PHP version change, or EasyApache rebuild
• Monitor /var/log/cagefs.log for unusual access denials
• Periodically audit which accounts have CageFS disabled and document the reason
• Keep CloudLinux packages updated: yum update regularly

Documentation for Your Team

• Document which accounts have CageFS disabled and why (legitimate developer shell access, etc.)
• Establish a process for adding new binaries to the skeleton when requested by users
• Create a runbook for common CageFS troubleshooting scenarios

---

Frequently Asked Questions About CloudLinux Site Isolation

Q: Does CloudLinux Site Isolation work with WordPress Multisite (WPMS)? A: Yes. WordPress Multisite operates entirely within a single cPanel user’s account, so all files remain within that user’s CageFS cage. WPMS functionality is unaffected by Site Isolation.

Q: Can I use CloudLinux Site Isolation with Nginx instead of Apache? A: Yes, with configuration. CageFS works with Nginx + PHP-FPM setups. The key is ensuring PHP-FPM pools run as the individual cPanel users rather than a shared Nginx user. With cPanel’s Nginx reverse proxy (via EasyApache), this is handled automatically.

Q: Will CageFS break any cPanel features? A: The vast majority of cPanel features work normally inside CageFS. A small number of advanced shell operations may require adding binaries to the skeleton. Refer to CloudLinux’s official compatibility documentation for a full list.

Q: Does Site Isolation help with brute force and DDoS attacks? A: Directly, no — those are network-level threats handled by Imunify360’s IDS/IPS and WAF. However, Site Isolation prevents a successful intrusion from being used as a base for further attacks on other accounts.

Q: Is CageFS compatible with cPanel’s Reseller accounts? A: Yes. Reseller accounts and all sub-accounts managed by resellers are enrolled in CageFS individually. The reseller’s own files are isolated from their sub-accounts as well.

Q: Can a cPanel user disable their own CageFS protection? A: No. CageFS is managed exclusively at the root/WHM level. Individual cPanel users cannot enable or disable their own cage.

Q: What happens to a user’s files when CageFS is enabled on an existing account? A: Nothing changes in the user’s actual home directory. Enabling CageFS only changes the mount namespace presented to that user’s processes — their files remain untouched.

---

Conclusion: Why CloudLinux Site Isolation Is Non-Negotiable for cPanel Shared Hosting

In today’s threat landscape, where WordPress vulnerabilities are disclosed daily, automated exploit scanners constantly probe for weak plugins and themes, and malware campaigns actively target shared hosting environments for mass compromise, CloudLinux Site Isolation is not a luxury — it is a fundamental requirement for responsible shared hosting operation.

The combination of CageFS (per-user filesystem namespace isolation), SecureLinks (kernel-level symlink/hardlink attack prevention), LVE (resource isolation), and PHP-FPM per-user pools creates a multi-layered security architecture that contains compromises, prevents lateral movement, eliminates entire classes of cross-account attacks, and protects your customers’ data even when individual WordPress sites are successfully hacked.

For WHM and cPanel hosting providers — whether running a small reseller operation or a large-scale hosting business managing thousands of accounts — enabling CloudLinux Site Isolation is the single highest-impact security investment you can make. It reduces incident response costs, prevents mass data breaches, improves customer trust, and fundamentally changes the blast radius of a compromise from “server-wide emergency” to “contained single-account incident.”

Paired with Imunify360 for real-time malware scanning and web application firewall protection, CloudLinux Site Isolation forms the bedrock of a truly hardened, enterprise-grade shared hosting environment built on cPanel and WHM.