CRITICAL: LiteSpeed cPanel Plugin Zero-Day Gives Any Hosting User Root (CVE-2026-48172)

There is a particular flavor of vulnerability that ruins weekends in the hosting industry, and LiteSpeed just shipped one. CVE-2026-48172 is a CVSS 10.0 privilege escalation zero-day in the LiteSpeed User-End cPanel Plugin that lets any authenticated cPanel user execute arbitrary scripts as root on the underlying server. Not a sandboxed user account, not the limited environment that shared hosting customers are supposed to be stuck inside, and not even the WHM administrator. Root on the box. The bug was already being exploited in the wild when LiteSpeed pushed the fix, which puts every shared hosting provider running the affected plugin in the unenviable position of having to assume their boxes were already touched.

The flaw lives in a JSON-API endpoint exposed by the plugin called lsws.redisAble, which is reachable to every logged-in cPanel user by default. That last detail is the part that turns this from a bad bug into a catastrophe. cPanel is the management plane that shared hosting customers use to control their slice of a server, and the entire security model of shared hosting rests on the assumption that one customer's account cannot escape into the host or into a neighbor's space. CVE-2026-48172 collapses that boundary completely. Any account, including any account that an attacker phishes, buys on a stolen credentials market, or spins up on a hosting provider's free trial, gets root execution on the entire physical machine. That root execution lands the attacker on a server that is by definition hosting many other tenants, each with their own websites, databases, customer data, and active sessions.

The disclosure timeline reads like a competent vendor doing what a vendor is supposed to do, and it still left the world exposed. South African security researcher David Strydom reported the issue to LiteSpeed on May 19, 2026. LiteSpeed shipped fixed versions the same day, requested a CVE on May 20, completed an internal security review on May 21, and pushed additional patched releases. The advisory went public on May 23 alongside confirmation that the vulnerability was being actively exploited in the wild. That sounds like a fast response, and on the vendor's side it absolutely was. The catch is that the actual deployment of a cPanel plugin update across the global hosting ecosystem does not happen automatically on most boxes, and the window between fix availability and customer rollout is exactly the window that attackers are racing to exploit. Several days into that window now, a meaningful percentage of LiteSpeed-fronted hosting servers are still running the vulnerable plugin.

Affected versions are LiteSpeed User-End cPanel Plugin 2.3 through 2.4.4. The fix is in 2.4.5 and later, with LiteSpeed recommending 2.4.7 as the version to land on. The WHM-side plugin, which is the administrator-facing component, is not impacted by this specific bug. That distinction matters because hosting providers tend to think about LiteSpeed as a single product family, and the natural temptation is to check WHM and conclude things are fine. They are not. The vulnerable surface is the user-end plugin that exists on a box for the benefit of every cPanel account on that box, and the WHM plugin being healthy says nothing about whether the user-end plugin has been patched.

The mechanics of the bug are a textbook example of how internal API endpoints get treated as more privileged than they actually are. The lsws.redisAble function was apparently designed to handle Redis cache toggling for the LiteSpeed web server stack on a per-account basis. Toggling cache settings is a legitimate per-user action, so the endpoint was exposed to every cPanel user. The problem is that the implementation invokes commands at root rather than dropping privileges to the calling account, and the input handling allows the calling user to influence which scripts get run with that root context. Combine an endpoint that any user can call with a privilege boundary that the endpoint forgets to enforce, and you have arbitrary root execution from a low-privilege starting point. This is the kind of pattern that shows up in vendor code over and over again, usually because the original developer trusted that the API layer above the function would handle authorization, and the API layer above the function trusted the function to handle it.

There are no good half measures here. The fix is to upgrade the User-End cPanel plugin to at least 2.4.7. For administrators who cannot upgrade immediately, LiteSpeed has documented a workaround that involves removing the user-end plugin entirely with the command /usr/local/lsws/admin/misc/lscmctl cpanelplugin --uninstall run from the server. That is a real mitigation rather than a token suggestion, because it physically removes the vulnerable endpoint from the system. The tradeoff is that customers lose the user-facing controls the plugin provides, but losing optional UI is a price worth paying compared to losing the box. Anyone running a fleet of hosting servers should treat this as an emergency change. Pulling the plugin off the boxes that cannot be patched tonight is the right answer, and re-installing the patched plugin after the maintenance window closes is straightforward.

Detection is where this gets serious. LiteSpeed has published an indicator of compromise that any hosting administrator can run immediately to look for past exploitation attempts. Searching the cPanel logs for the string cpanel_jsonapi_func=redisAble inside /var/cpanel/logs and /usr/local/cpanel/logs will surface every historical invocation of the vulnerable endpoint, and any hit deserves investigation rather than dismissal. Many of those hits will be legitimate, because the endpoint has a legitimate purpose, but a sudden burst of requests from a single account, requests from accounts that have no business calling cache management functions, or requests that correlate with the appearance of unexpected processes running as root are all signs that the attacker got there first. Boxes that show signs of exploitation should be treated as compromised hosts, which in a shared hosting context means assuming that every tenant on that host is also potentially affected. That is not a polite assumption to deliver to customers, and it is the correct one.

The scale of exposure is significant. LiteSpeed Web Server is one of the most widely deployed alternatives to Apache and Nginx in the shared hosting world, and the cPanel plugin is bundled or recommended by a large number of hosting providers including some of the names that anyone who has ever bought a website has heard of. The user-end plugin specifically is the component that customers interact with for cache controls, so it tends to be enabled by default on hosting plans that emphasize WordPress performance. That means the vulnerable surface overlaps almost perfectly with the population of small business and SMB websites that hosting providers are constantly trying to upsell into managed WordPress plans. Those are exactly the customers least likely to be running their own security monitoring, and exactly the customers most likely to discover a compromise weeks later when their hosting provider notifies them by email.

For MSPs whose customers depend on shared hosting, this is a moment to pick up the phone. Customers running websites on third-party hosting often have no idea what web server software their provider uses, and they certainly do not know whether their host has patched a plugin they have never heard of. A short outreach explaining that there is an active zero-day affecting the most common alternative to Apache in shared hosting, that any compromised cPanel account on a vulnerable server can take over the entire box, and that the right move is to confirm patch status with the hosting provider and review recent activity on the cPanel account, opens the door to a broader conversation about why depending on a hosting provider's security posture is a strategy and not an absence of one. Offering to handle the provider conversation, validate the patch level, audit the cPanel account for unauthorized changes, and rotate any credentials that touched the box is a billable engagement with a clear scope and a deliverable that customers can understand. Following that up with a pitch on managed hosting on infrastructure under the MSP's control, or at minimum on a backup and monitoring program that does not depend on the hosting provider noticing problems, is a natural next conversation.

The bigger lesson is one the industry keeps relearning. Privilege boundaries that exist only at the API layer and not at the implementation layer are not privilege boundaries. They are documentation. Every hosting platform that exposes a JSON API to low-privileged users carries the same risk surface that LiteSpeed just demonstrated, and the only durable mitigation is design discipline that drops privileges before performing actions on behalf of a user rather than relying on the framework to filter callers. Hosting providers should be asking every plugin vendor in their stack to confirm that user-callable endpoints actually run as the calling user, and they should be treating those endpoints as the highest-priority audit target on the entire box. The next CVE-2026-48172 is already in somebody's plugin code right now, waiting for a researcher to notice it or, more likely, an attacker to notice it first.