A cPanel Account Just Became a Root Shell: What CVE-2026-87899 Means for Shared Hosting

If you run a shared hosting box on cPanel & WHM, stop what you’re doing and check your build number. On September 22, cPanel shipped fixes for three separate vulnerabilities, and the headline one, CVE-2026-87899, is about as bad as it gets on a multi-tenant server: any logged-in cPanel account can run code as root and take over the entire machine.

We’ve spent years cleaning up compromised hosting environments, and this is the exact class of bug that turns a single throwaway account into a full server breach. Below is what actually matters, why it’s dangerous in practice, and what to do today.

The short version

cPanel’s CalDAV and CardDAV service, the piece that stores each account’s calendars and contacts, contains a privilege escalation flaw. cPanel’s own advisory puts it plainly: successful exploitation leads to code execution as root, giving an attacker full control of the server. The only precondition is having a cPanel account. No admin access, no special role, no chained zero-day. Just an account.

Two more flaws landed in the same batch:

• CVE-2026-87900, a bug in WP Toolkit’s database-creation logic that lets one logged-in cPanel user modify databases belonging to other accounts on the same server.
• CVE-2026-68490, a lower-severity issue in the same CalDAV/CardDAV service where a local user can read other accounts’ calendar events and contacts (read-only, no root).

All three were reported by researcher Ali Mustafa, who goes by rz1027, the same handle credited on a string of recent cPanel and Plesk findings.

Why the root flaw is the one that keeps us up at night

Here’s the thing people underestimate about shared hosting: the whole business model assumes tenant isolation actually holds. A hundred customers, a hundred cPanel accounts, one kernel underneath. The security boundary between “some customer’s website” and “the box that runs everyone’s websites” is supposed to be solid.

CVE-2026-87899 erases that boundary. Think through who has “a cPanel account” on a typical provider:

• Every paying customer, including the one who signed up 20 minutes ago with a stolen card.
• Anyone who phished, credential-stuffed, or otherwise got hold of a single customer’s login.
• Any low-value site on the server that’s already been compromised through an unrelated bug, a stale WordPress plugin, a weak password, whatever.

Any one of those becomes root. And root on a shared server means every site on that machine: database dumps across all tenants, planted webshells, mass defacement, credential harvesting from config files, or a quiet foothold for later. In our hacked website cleanup work, the pattern is almost always the same: the initial break-in happens on the least important account on the box, and the privilege escalation is what makes it a disaster instead of an annoyance.

The advisory doesn’t publish exploit mechanics, and that’s appropriate this early. But CalDAV/CardDAV handling code that touches per-account file permissions is a classic escalation surface, the service runs with elevated privileges to manage every account’s calendar store, so a flaw in how it processes an authenticated user’s request is a direct line from “unprivileged account” to “root context.” cPanel even notes that the update repairs calendar and contact permissions on existing accounts, which tells you permissions were part of the story.

Affected and fixed versions

The CalDAV/CardDAV flaws (both -87899 and -68490) affect cPanel & WHM v120 and later. Patched builds are:

The WP Toolkit flaw (CVE-2026-87900) is separate. It affects WP Toolkit 6.11.2-10794 and older, and is fixed in 6.11.3 or later. Worth flagging: WP Toolkit is a distinct package (wp-toolkit-cpanel) with its own update path, updating cPanel & WHM does not update it. We’ve seen plenty of servers where the panel is current but a bundled add-on is months behind, so don’t assume one update covers both.

What to do right now

1. Patch cPanel & WHM

In WHM, go to Home » cPanel » Upgrade to Latest Version, or run this as root:

/usr/local/cpanel/scripts/upcp --force

The upgrade also fixes the calendar/contact permission state for accounts that already exist on the server.

2. Update WP Toolkit separately

If you have WP Toolkit installed, pull 6.11.3 explicitly:

bash <(curl https://wp-toolkit.plesk.com/cPanel/installer.sh || wget -O - https://wp-toolkit.plesk.com/cPanel/installer.sh) --version 6.11.3

cPanel hasn’t confirmed whether auto-updates will roll 6.11.3 out on their own, so treat this as a manual job until you’ve verified the version. If your sites run on WordPress specifically, this is also a good moment to review your broader WordPress security posture rather than just the toolkit version number.

3. If you can’t patch immediately

There’s no official workaround for the root flaw, the fix is the update, full stop. That makes it a scheduling problem, not an optional one. On any server you can’t touch tonight, our practical advice from cleanup work:

• Treat the window between now and patch as active exposure. Assume the flaw is reachable by anyone with an account.
• Watch for new account signups and sudden activity from dormant accounts, that’s how opportunistic abuse tends to start on shared boxes.
• Review who currently holds accounts and kill any you don’t recognize.
• A web application firewall in front of your hosting panel and customer-facing services won’t patch this bug, but it does cut down the number of accounts an opportunistic attacker can reach in the first place while you get the update scheduled.

Is it being exploited?

As of September 23, none of the three advisories mention in-the-wild exploitation, and none of the CVEs were listed in CISA’s Known Exploited Vulnerabilities catalog. That’s genuinely good news, but it’s a snapshot, not a guarantee. Root RCE on cPanel is high-value, the panel runs on a huge slice of the shared-hosting market, and a bug this clean tends to attract attention fast once details circulate. The absence of detection guidance in the advisories also cuts the other way: cPanel doesn’t provide a way to check whether a given server was hit before it was updated, so “we saw nothing” is not the same as “nothing happened.” If you’re patching a box that sat exposed, err toward a post-update integrity review rather than assuming you’re clean. That’s exactly the kind of check our hacked website repair team does after a patch like this: confirm nothing was already planted before you close the door.

The bigger pattern

This isn’t an isolated slip. The same researcher has been credited with at least seven cPanel and Plesk flaws since late August, several of them privilege-escalation issues that end in root or full server takeover, including a WP Toolkit-adjacent EmailTrack RCE earlier in September and two Plesk Backup Manager bugs. Both products come from the same vendor, WebPros, and share components; cPanel hasn’t said whether the Plesk build of WP Toolkit carries the -87900 flaw, which is a question Plesk operators should be asking their vendor directly.

The takeaway for anyone managing hosting infrastructure: the control panel is your attack surface, not just the sites on top of it. Patch cadence on cPanel/WHM and its add-ons deserves the same discipline you’d give a public-facing application, because on a shared server one unpatched escalation bug hands over everyone at once. If you’re evaluating hosting providers precisely because of stories like this one, that discipline is the whole reason we run secure web hosting the way we do, and if you manage your own servers and want an outside check on how they’d actually hold up, that’s what our penetration testing service and server management team are for.