SURIQ
A control-panel plugin that runs as root has no business trusting filesystem state an unprivileged tenant controls. The LiteSpeed cPanel plugin did exactly that, and it did it twice this year. Two separate bugs, CVE-2026-54420 and CVE-2026-48172, each let an ordinary shared-hosting account reach root on the box. Both now sit on CISA's Known Exploited Vulnerabilities list. Both were used in real attacks before most operators had finished patching.
If you run cPanel hosting with the LiteSpeed plugin, this is today's work, not next sprint's. CISA gave federal agencies three days on the newer bug: a June 15 listing, a June 18 deadline. That compressed clock is the tell. The usual KEV window is three weeks, so a three-day one means the agency is confident the attacks are already running at scale.
What actually broke
CVE-2026-54420 is a symlink-following bug, classed as CWE-61, scored 8.5 on CVSS. Before version 2.4.8, which ships inside LiteSpeed's WHM plugin and is fixed at 5.3.2.0, the plugin follows symbolic links a tenant plants in their own account. Someone who already has web-shell or FTP access to a shared host running CloudLinux and CageFS can aim one of those links at a file outside their account and have the root-privileged plugin act on it. The CVSS vector flags the scope as changed, which is the formal way of saying the damage crosses the boundary the account was meant to stay inside. The OffSeq threat record carries the full CVSS vector and the in-the-wild note for May 2026.
CVE-2026-48172 is the older of the pair and the uglier on paper: a CVSS 10.0 incorrect-privilege-assignment flaw that let any authenticated cPanel user run scripts as root. It hit plugin versions 2.3 through 2.4.4 and was closed in 2.4.5. cPanel treated it as an emergency. Its May 19 patch shipped a mitigation that pulled the vulnerable plugin off affected servers outright, a detail the CyCognito writeup walks through.
Are these LiteSpeed cPanel bugs being exploited right now?
Yes. Both CVE-2026-54420 and CVE-2026-48172 are on the CISA KEV catalog, which lists only flaws with confirmed exploitation in the wild. The symlink bug was used in attacks during May 2026, and the privilege-assignment bug drew an emergency cPanel patch the same month. KEV listing on a hosting plugin is a signal to patch first and ask questions after.
Why CageFS did not save you
Shared hosting sells one promise above the rest: the account next to yours on the same box cannot read your files, and you cannot read theirs. CageFS is how most cPanel hosts keep it, handing every account a thin, isolated view of the filesystem. Both of these bugs walk around it. The plugin does not live inside the cage. It runs with full privilege so it can do per-account work, and when it follows a tenant-supplied path or runs a tenant-named script, it carries that privilege straight through the wall the cage exists to hold. The jail is not the weak point. The privileged helper that reaches into every cell is.
That is the same failure that keeps surfacing in software built to do privileged work for unprivileged users. We saw a version of it when PeopleSoft's PSEMHUB update service turned into the path onto the host instead of the thing keeping it patched. A component earns root to do its job, then trusts input from someone who has none. The repair is never "validate the attacker's input more carefully." It is "stop acting on attacker-controlled paths with privileges the attacker does not hold."
The pattern, not the two bugs
Two root-escalation flaws in one plugin in one year is not bad luck. It is a design that gives a single helper both root and a steady feed of tenant-controlled input, then leans on validation to keep the two apart. The class is older than cPanel. It is why setuid binaries are audited to death and why anything that opens a path on behalf of a lower-privileged caller should resolve and pin that path before it touches it. A symlink check that runs after the open is theater.
There is a second lesson hiding in the timeline. When a hosting vendor reaches into your servers and removes one of its own plugins, as cPanel did on May 19, that is the loudest "stop using this now" you will ever get from an upstream. Treat plugin auto-removal events as a page-the-on-call signal, not a changelog footnote. The vendor already decided the risk was worse than the downtime.
What to do before the deadline
-
Update the LiteSpeed cPanel plugin to
2.4.8or later, distributed in LiteSpeedWHMplugin5.3.2.0or later. That closes CVE-2026-54420. -
Confirm you are past
2.4.5for CVE-2026-48172. If cPanel's May mitigation already removed the plugin, verify what you reinstall is the fixed build, not a rollback. -
Check version parity across the whole fleet. One unpatched node on a shared platform is the entire risk, because every tenant on it is a potential foothold.
The hunt, assuming you were exposed
Patching shuts the door. It does not tell you whether someone already walked through. On any box that ran the vulnerable plugin before you updated, the account boundary cannot be trusted for the exposure window, which on the symlink bug reaches back to early May. This is the same patch-then-hunt discipline we wrote up for Ivanti Sentry, where the fix closed the bug but not the breach. On these hosts, go looking for:
-
Symlinks in account home directories that resolve to paths outside the account. The plugin following one of those is the exact exploit primitive.
-
Root-owned files created in or from account context, especially scripts dropped under account directories around the May exploitation window.
-
New WHM or cPanel users, reseller accounts, or SSH keys added after early May that nobody on your team can account for.
-
Any process spawned by the plugin that read or wrote outside the tenant's caged view.
A root foothold on a shared host is not one customer's problem. It is every account on that machine, plus whatever the attacker staged for persistence before you patched. The privileged helper that quietly reaches across tenant walls is one of the most reliable escalation primitives on a hosting platform, and this is the second time in a year it paid off against the same plugin. Audit anything on your fleet that runs as root to serve unprivileged users. That is where the next one of these lives. It is the same blind spot we keep flagging in the auth and access stack that sits below the application.