What Is CageFS? Per-User Filesystem Isolation, Explained

What CageFS is

CageFS is a feature of CloudLinux OS that gives every hosting account its own virtualized, per-user filesystem. The name is literal: each user is placed in a cage, a restricted view of the server that looks, from inside, like a complete Linux system but contains only that user's files and a safe, shared set of tools. Hundreds of accounts can live on one physical server, and each one behaves as if it were alone on the machine.

The problem CageFS solves is specific. On a plain Linux server with cPanel, every account technically shares one filesystem. File permissions are supposed to keep users apart, but permissions are brittle: a world-readable config file, a misconfigured directory, or a clever symbolic link can expose one account's data to another. On shared hosting, where you do not choose your neighbors, that is a real risk. CageFS removes the risk at the root by making the other accounts simply not exist from any given user's point of view.

What CageFS isolates

Inside the cage, an account sees a filesystem assembled just for it. There are three parts to that view:

• The user's own files. The home directory, websites, databases sockets, uploads, and logs that belong to this account, exactly as normal.
• A shared, read-only toolset. The binaries and libraries an account needs to run (the shell, PHP, common utilities) are mounted read-only from a template. Every user shares the same copy, and none of them can modify it.
• A safe, virtualized view of system directories. Directories like /etc and /proc are replaced with sanitized versions that expose only the current user's own entries.

Just as important is what an account cannot see from inside its cage:

• Other customers' home directories, websites, or uploads
• Other users' configuration files, including WordPress wp-config.php and .env files that hold database passwords and API keys
• The full list of user accounts on the server (a real /etc/passwd would enumerate every customer)
• The full process table, so it cannot watch what other sites are running
• The real system layout and sensitive files attackers read to plan privilege escalation

The virtualized /etc and /proc

The two virtualized directories deserve a closer look, because they are where a lot of information disclosure normally happens.

On a normal system, /etc/passwd lists every user account on the machine. An attacker who lands in one account reads it to learn every other username, which is the first step to targeting specific sites. Inside a CageFS cage, the /etc directory is a curated template: the passwd file shows only the caged user and the handful of system accounts needed for programs to run. There is no list of your neighbors to steal.

Similarly, /proc on a normal system exposes the full process table, including processes owned by other users and sometimes their command lines and environment variables. CageFS mounts a filtered /proc that shows only the current user's own processes. An attacker cannot watch a neighbor's PHP process or scrape secrets passed on a command line.

Why CageFS stops information-disclosure and symlink attacks

Most shared-hosting breaches that spread beyond one account rely on one of two moves, and CageFS neutralizes both.

Information disclosure

The classic pivot: an attacker compromises one weak site, then reads the server for other sites' database credentials and configuration files. Every one of the files they want to read, a neighbor's wp-config.php, a real /etc/passwd, another user's logs, either does not exist inside the cage or is replaced with a version that shows only the attacker's own account. The attack returns nothing useful, so a single compromise stays contained to the one account instead of becoming a server-wide breach.

Symlink attacks

A symlink (symbolic link) attack plants a crafted link so that a privileged process follows it to a file the attacker should not be able to read or overwrite, often another account's config. CageFS helps directly, because the target file is not present inside the cage to begin with. CloudLinux pairs CageFS with SecureLinks, a kernel-level protection that specifically blocks the symbolic-link and hard-link tricks these attacks depend on. The link trick is blocked and the target it aims for is hidden.

How CageFS relates to LVE and the PHP runtime

CageFS is often confused with LVE because both are CloudLinux features that isolate accounts, but they solve different problems and work together.

LVE, the Lightweight Virtual Environment, is about resource isolation: it caps each account's CPU, memory, disk I/O, and process count so one busy site cannot slow the whole server. CageFS is about filesystem isolation: it controls what each account can see and read. A host runs both, so every account is limited both in what it can consume and in what it can reach.

The two meet at the PHP runtime. CloudLinux executes an account's PHP (typically through mod_lsapi and the per-user task runtime sometimes referred to as MTR) inside that account's own cage and LVE. The practical effect is that the PHP interpreter serving one site runs with that site's limited, isolated view of the filesystem. Even if a script is malicious, it cannot step outside the cage to read a neighbor's files, and it cannot exceed that account's resource limits. CageFS defines the boundary, and the runtime respects it.

What CageFS does NOT do

This is the honest half, and it matters because CageFS is sometimes described as if it were a complete security solution. It is not. CageFS is isolation, not detection or prevention of attacks inside your own account.

• It is not a malware scanner. CageFS will not find, flag, or remove malicious code that lives inside your own account. If your site gets infected through a vulnerable plugin, the malware runs happily inside your cage. Detecting and cleaning it is the job of a scanner like Imunify360.
• It is not a web application firewall. CageFS does not inspect incoming HTTP requests, so it will not block an SQL injection, a cross-site scripting payload, or a malicious file upload aimed at your application. That is what a WAF does.
• It is not a substitute for good application security. CageFS cannot patch a vulnerable plugin or theme, cannot stop an attacker who has your real password, and cannot undo a site that leaks its own credentials. Keeping software updated and using strong unique passwords stays with the site owner.

How Ultra uses CageFS

Ultra Web Hosting runs CloudLinux with CageFS and LVE across our shared hosting and reseller hosting, so every account is isolated at both the filesystem and the resource level, with Imunify360 adding the active malware and WAF layer on top. All of it runs on hardware we have owned and operated since 2002, in our own datacenter, with on-site staff available 24/7 and a typical support response around twelve minutes. There is no separate security add-on charge on shared hosting plans. For the wider picture of how the isolation and detection layers fit together, read our guide on CloudLinux, CageFS, and Imunify360, and if you are weighing shared hosting in general, see is shared hosting secure.