The symlink that walks out of the jail: privileged link-following on shared hosting

This continues our series on the trust boundaries that a front-door scanner cannot see. The boundary here is not at the network and not at the login. It is inside the file system, between a low-privileged tenant and the high-privileged process that maintains its files, and the thing that crosses it is a single symlink. Verifiable security.

The attack pattern in one paragraph

A shared-hosting platform isolates each tenant in a chrooted or namespaced jail, on CloudLinux this is CageFS, so the tenant sees only its own files and a curated set of system binaries. But the control panel and its plugins run with high privilege and routinely step into each tenant's directory to do maintenance: rotate a cache, fix up permissions, read a config, write a log. When that privileged process opens a path inside the tenant's space without first resolving and validating that the path stays inside the jail, the tenant can replace an expected file with a symbolic link pointing somewhere it should never reach, a root-owned config, a file outside CageFS, another tenant's data. The privileged process follows the link and performs its operation on the target, with its own privileges, not the tenant's. A permission change meant for the tenant's cache file is applied to a root-owned file. A write meant for the tenant's log lands outside the jail. The low-privileged attacker never gained a single permission directly; they borrowed the privileged helper's permissions by pointing it at a target of their choosing. In CVE-2026-54420 the privileged actor is the LiteSpeed cPanel plugin, the planted artifact is a symlink from a tenant with FTP or web-shell access, and the outcome is root on a shared server holding many other tenants.

The unifying observation: a jail confines the unprivileged. It does not, by itself, confine a privileged process that walks into the jail trusting the paths it finds there. The tenant cannot escape the jail. The tenant can, however, hand the jailer a map that leads outside it.

Why this still ships in 2026

If shared-hosting isolation is decades old and symlink attacks are textbook, why does a link-following flaw still reach a CISA exploited-vulnerabilities listing? Three structural reasons, each verifiable against your own platform.

1. The check and the use are separated in time. A privileged maintenance routine often validates a path, "is this inside the tenant's directory? yes", and then, a moment later, opens it. Between the check and the open, the tenant swaps the path for a symlink. This time-of-check-to-time-of-use race, CWE-367, is the engine under many link-following bugs: the path that was safe when checked is malicious when used. The fix is not a better check; it is to never separate the check from the use, by opening with flags that refuse to follow links and operating on the resulting handle.
2. Privileged helpers are trusted to stay in their lane. The plugin author reasons that the plugin only ever touches the tenant's own files, so following a link "within" that directory feels harmless. But a link is not data; it is a redirection, and a tenant who can write a file can write a link. The privileged process inherits the danger of every path it opens, and inside a tenant-writable directory, every path is attacker-influenced.
3. The jail creates false confidence. CageFS and chroot are real, strong isolation for the unprivileged tenant, and their presence makes everyone assume the file system is safe. But the jail constrains the tenant's process, not the control panel's. A root plugin operating across jails is precisely the actor the jail does not contain, and it is the one whose mistakes convert a tenant's web shell into root.

The attacker decision tree

The decisive crossing is step 2 to step 3: the moment a root-privileged plugin opens a tenant-planted symlink without refusing to follow it, the jail that confines the tenant is irrelevant.

The decisive junction is step 2 to step 3. Everything before it is something an unprivileged tenant can do inside its own jail: write a file, and replace that file with a symlink. The escalation happens entirely in the privileged process, when it opens the planted path and follows the link with its own authority. The tenant never touched a root-owned file directly. They arranged for root to touch it on their behalf.

A walk through the boundary crossing

To make the crossing concrete, here is the shape of the path CVE-2026-54420 describes, with the destructive final step omitted. The attacker holds a low-privileged position on one tenant of a shared server, FTP write access or a web shell on a single site, and the host runs a control-panel plugin that performs privileged maintenance inside tenant directories.

Step 1, hold the foothold. The attacker controls one tenant account. Inside CageFS they can read and write their own files and nothing else. A direct attempt to touch a root-owned or cross-tenant file is denied, exactly as the jail intends.

# Inside the tenant jail: writing own files works, reaching out does not.
$ id
uid=1007(tenant07) gid=1007(tenant07)
$ cat /etc/shadow                       # denied: the jail holds for the tenant
cat: /etc/shadow: Permission denied

Step 2, plant the link. The attacker knows the privileged plugin will, on its next maintenance pass, open a known path inside their directory, a cache file, a marker, a log. They replace that expected file with a symlink pointing at a target outside the jail.

# Replace the path the privileged plugin will open with a link out of the jail.
# (Illustrative target; the real impact depends on what the plugin does with it.)
$ rm -f ~/.lscache/marker
$ ln -s /root/.ssh/authorized_keys ~/.lscache/marker

Step 3, let the jailer follow it. The plugin runs its maintenance with high privilege, opens ~/.lscache/marker, and because it does not refuse to follow links, it follows the symlink to the root-owned target and performs its operation there, a write, a permission change, an ownership change, with root's authority rather than the tenant's.

# The privileged plugin opens the planted path and follows the link:
#   open("~/.lscache/marker")  ->  resolves to /root/.ssh/authorized_keys
# A write meant for a tenant cache lands in a root-owned file.
# A chmod meant for a tenant file loosens a root-owned file.
# No tenant ever held root. The plugin lent it, one symlink at a time.

Step 4, the impact, and the omitted step. At this point the escalation primitive exists: the attacker can steer a root-privileged write, read, or permission change at a target of their choosing. The destructive completion, planting a key, loosening a sensitive file, rewriting another tenant's content, is left to the imagination and not to this page. The point is made at step 3: the privileged process followed a link it should have refused.

No memory corruption, no zero-day in the kernel, no cracked password. Each step is a privileged plugin doing exactly what it was built to do, on a path an unprivileged tenant arranged for it to find. The jail that confines the tenant is intact throughout, and irrelevant, because the actor that crossed it was never the tenant.

Why scanners miss the link-following boundary

This class survives a clean external report because the dangerous property is a relationship between two facts that no front-door crawl observes: a privileged process opens paths inside a tenant-writable directory, and it does so without refusing to follow symlinks. Neither fact is visible from the outside.

• Web scanners test the application, not the maintenance helper. They crawl the hosted sites and the control-panel login, and they correctly report those. The privileged plugin's file-system behavior on the host is not part of any HTTP surface they can reach.
• Version scanners match a banner, not a behavior. A plugin version can be fingerprinted, but whether that version opens tenant paths with link-following refused is a property of the code path, not the banner. The exposure depends on configuration and code, not on a number alone.
• The precondition is an authenticated tenant. The attacker needs a foothold in one tenant, which an external scan does not have and should not simulate against a live multi-tenant host. The danger is what that foothold becomes, and only a model of the privileged helper's file handling reveals it.

What to do about it: refuse the link, do not validate the path

The leverage in defense is that you do not have to anticipate every file an attacker might link to. You have to make the privileged process refuse to follow links into attacker-writable space at all. Cut that one behavior and the tree collapses regardless of what the tenant plants.

A jail confines the unprivileged. It does not confine the privileged helper that walks into the jail trusting the paths it finds there. The tenant cannot leave. The tenant can hand the jailer a map that leads out.

The cheapest first move for a hosting operator this week: patch the plugin, then inventory every privileged process that opens files inside tenant-writable directories and confirm each one refuses to follow symlinks at open time. That single audit surfaces the exact edge in every walk above, and it does not depend on guessing what an attacker would link to.

How Celvex catches this

Where we sit honestly: this is a flaw whose exploitation requires an authenticated tenant foothold, which we do not simulate against a live shared host. What we do safely and at breadth is detect the vulnerable component and version band from a read-only vantage, map it to its public CVE, and ship a reproducible Capsule for the exposure, so the operator can prioritize the patch before an attacker with a tenant foothold reaches it. You can see the evidence format on the Proof Capsule page and the methodology in our zero-false-positive doctrine.

Bottom line

Shared-hosting isolation is a promise about the file system, and the file system trusts a symlink. CVE-2026-54420 (CVSS 8.5, CWE-61) is the clean case: a low-privileged tenant with FTP or web-shell access plants a symlink, the root-privileged LiteSpeed cPanel plugin follows it out of the CageFS jail, and the tenant borrows root's authority to escalate, a flaw CISA confirmed under active exploitation on 16 June 2026. Front-door scanners miss it because the vulnerability is the privileged helper's file handling inside a tenant-writable directory, not anything reachable over HTTP. The fix is leverage: refuse to follow links at open time, operate on handles, drop privilege where you can, and patch to the fixed release, and the whole tree collapses regardless of what the tenant plants. Then prove the privileged path no longer follows the link, and verify the proof held.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held. That is what we ship.