cPanel CVE-2026-87899: What WordPress Hosts Should Check

CVE-2026-87899 lets anyone with a cPanel login run code as root, and CVE-2026-87900 lets a cPanel user reach other accounts through WP Toolkit.^[1][2][3] Update cPanel to a fixed build and WP Toolkit to 6.11.3, separately. On shared hosting, ask your host to confirm both.

cPanel published the advisories on September 22, and CVE records followed on September 23.^[1][2][3] The advisories don’t mention exploitation, and cPanel gives no temporary workaround.^[5] That makes this a patch-and-confirm job, not an incident. The catch is that WP Toolkit ships as its own package, so don’t count on a cPanel update to cover the WordPress side.^[5]

TL;DR: What to do right now

1. Server admins: run cat /usr/local/cpanel/version and compare it with the fixed builds in the table below.^[7] If it’s older, update cPanel & WHM.^[6]
2. Check WP Toolkit separately. Anything at 6.11.2-10794 or older needs 6.11.3.^[2]
3. Agencies with several servers: check every box, not just the one you log into most. The loop below does it in one pass.
4. Shared-hosting customers: ask your host which cPanel build and WP Toolkit version your server runs, and when it was updated.
5. Everyone: list your WordPress administrators and remove any you don’t recognise. It takes a minute and needs no server access.

What CVE-2026-87899 and the WP Toolkit fix cover

One researcher, Ali Mustafa (rz1027), reported all three issues, and they were fixed in the same release.^[1][2][5]

The root bug affects cPanel & WHM version 120 and later.^[1] The advisory lists fixes only for the builds above. If your server sits on a branch that isn’t listed, plan the move to a listed branch rather than waiting for a backport.

Why CVE-2026-87899 matters on shared hosting

The attacker needs a cPanel login, and on a shared server that’s the product the host sells. As The Hacker News put it, on a server where accounts are sold to the public, any customer could use it.^[5] Root means complete control of the server, and that covers every site hosted on it.^[1]

The WP Toolkit bug is worse in the CVE record than in the advisory

cPanel’s advisory for CVE-2026-87900 says a cPanel user could “perform database modifications in other accounts.”^[2] The CVE record, published a day later, goes further. It describes argument injection that lets authenticated users “read arbitrary files and execute arbitrary code across customer accounts,” and scores it 9.4 on CVSS 4.0.^[4] We’d plan around the CVE record’s wording. Either way the fix is the same: WP Toolkit 6.11.3.

How to check and update a cPanel server

1. Check the cPanel build

As root, read the version file. It prints the full build number in the same format as the advisory.^[7]

cat /usr/local/cpanel/version
# fixed: 11.134.0.57+, 11.136.0.41+, 11.138.0.8+

To update, use WHM’s Upgrade to Latest Version page, or run cPanel’s update script as root.^[6]

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

2. Check WP Toolkit on its own

WP Toolkit is installed as a separate package, wp-toolkit-cpanel, with its own update.^[5] The Hacker News notes cPanel doesn’t say whether automatic updates will install 6.11.3, so check rather than assume.^[5]

# AlmaLinux, Rocky, CloudLinux
rpm -q wp-toolkit-cpanel
# Ubuntu
dpkg-query -W wp-toolkit-cpanel

If it reports 6.11.2-10794 or older, install 6.11.3 with the vendor’s installer, which is the command cPanel’s advisory gives.^[2][5] We’ve split the URL into a variable so it fits on screen.

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

Rerun both checks afterwards. An update that didn’t take looks the same as one that did until you read the version.

3. Agencies: check the whole fleet

If you manage more than a couple of servers, put the hostnames in a file and check them together.

while read -r h; do
  echo "== $h"
  ssh -n root@"$h" 'cat /usr/local/cpanel/version;
    rpm -q wp-toolkit-cpanel'
done < servers.txt

On Ubuntu hosts, swap the rpm -q line for dpkg-query -W. Keep the output with the date. It’s your record that the fleet was patched.

If you’re on shared hosting

You can’t patch the server, and you shouldn’t need to. What you can do is ask a precise question and do a quick check of your own site.

• Ask your host whether your server is on cPanel 11.134.0.57, 11.136.0.41, 11.138.0.8 or later, and WP Toolkit 6.11.3 or later. A good host will answer with version numbers and a date.
• List your WordPress administrators and look for anyone you didn’t add. With WP-CLI that’s wp user list --role=administrator. Without it, use Users in wp-admin, filtered to Administrator.
• Keep a recent backup somewhere other than the same server, so a bad day on the host isn’t a bad day for your site.

None of the three advisories gives indicators of compromise, and none mentions exploitation.^[5] So we’re not going to hand you a list of files to hunt for. If your host can’t tell you the server is patched, that’s the answer you need to act on.

How this fits with this month’s WordPress patches

This one sits under WordPress rather than in it. Updating WordPress to 7.1.2 closes CVE-2026-87902 and the Comment2Shell comment flaw, but it does nothing for the control panel underneath.^[8] A fully patched WordPress site on an unpatched cPanel server is still exposed to whoever else has an account there.

Zero Spam doesn’t patch servers or control panels. What it does is filter spam and malicious submissions on WordPress comments, forms and registrations, through the free WordPress plugin or the API. If that’s useful, start on the free Explorer plan; code ZEROSPAM20 takes 20% off a paid license.^[9]

FAQ

About Ben Marshall

Full-stack Developer & Engineering Manager

Ben Marshall is a full-stack developer and engineering manager who loves building solid software and helping teams do their best work. He’s equal parts builder and coach—focused on practical architecture, clean implementation, and making collaboration easier (and faster) for everyone.

• WordPress.org