WP Toolkit CVE-2026-87900 is a critical vulnerability in the WP Toolkit component that cPanel servers use to manage WordPress sites. It affects WP Toolkit for cPanel 6.11.2-10794 and earlier and is fixed in WP Toolkit 6.11.3. This page sticks to what the vendor advisory and the official vulnerability record say, and separates that from general post-incident hygiene.
Applies to WP Toolkit for cPanel 6.11.2-10794 and earlier, fixed in 6.11.3; AlmaLinux, Rocky Linux, CloudLinux
Table of Contents
Short answer: update WP Toolkit to 6.11.3 or later on every cPanel server, confirm the installed package version (not just the cPanel build number), and if untrusted users had accounts on the server while it was vulnerable, review WordPress admin users, database users and recent file changes across accounts.
What the sources say
The two primary sources describe the same flaw from different angles:
- cPanel’s advisory (published 22 September 2026) says a security issue was found in the handling of database-creation commands in WP Toolkit, and that it allowed an authenticated cPanel user to perform database modifications in other accounts. Affected: WP Toolkit 6.11.2-10794 and older. Fixed: 6.11.3 or later. The advisory credits Ali Mustafa (rz1027) for the report.
- The NVD record (published 23 September 2026) classifies it as argument injection (CWE-88) in WP Toolkit for cPanel 6.11.2-10794 and earlier, allowing remote authenticated users to read arbitrary files and execute arbitrary code across customer accounts. The CVSS 4.0 base score of 9.4 (Critical) and the CWE-88 classification on the record were supplied by the CNA (HackerOne); NVD’s own analysis was still pending (“Awaiting Analysis”) when we checked on 1 October 2026. The record lists 6.11.3-10850 as the first fixed build.
Neither source publishes exploit details, and we do not speculate about the exact code path. The practical reading is simple: any cPanel user on a server with an affected WP Toolkit could reach data belonging to other accounts. On a shared or reseller server that is a cross-tenant issue and should be patched immediately.
Who is affected
- cPanel & WHM servers with WP Toolkit for cPanel at version 6.11.2-10794 or earlier.
- The attacker needs a cPanel login (their own account). Servers where every account belongs to the same trusted owner are at lower risk, but should still be patched.
- The advisory covers the cPanel build of WP Toolkit. Plesk ships WP Toolkit on its own schedule; check the Plesk changelog for your version rather than assuming either way.
Check your WP Toolkit version
WP Toolkit is a separately packaged component. A fully updated cPanel build does not prove the toolkit was updated, so check the package itself. On AlmaLinux, Rocky Linux and CloudLinux (RPM-based) servers:
rpm -qa | grep -i wp-toolkitOn most servers the package is wp-toolkit-cpanel; the version must be 6.11.3 or later. You can also see the version in WHM under WP Toolkit (the version is shown in the interface footer and about box). On Ubuntu-based cPanel servers use WHM or dpkg -l | grep -i wp-toolkit instead; we have not tested the commands on this page on Ubuntu. An empty result from a package query only means the query found nothing, so confirm in WHM before concluding that WP Toolkit is not installed.
To check a fleet of RPM-based servers from one place:
for h in server1 server2 server3; do
printf '%s: ' "$h"
ssh -o BatchMode=yes "root@$h" "rpm -qa | grep -i wp-toolkit || echo 'no wp-toolkit RPM found, check WHM'"
doneUpdate to 6.11.3
Follow the update method in cPanel’s advisory; it links the installer script to use when WP Toolkit has not updated itself. After updating, run the version check again and load WP Toolkit in cPanel for a test account to confirm it works.
If the package stays on an old version, look for the usual blockers before re-running the update:
- Automatic updates for WP Toolkit disabled in WHM.
- On RPM-based servers, the WP Toolkit repository excluded or disabled in
/etc/yum.repos.d/(check withdnf repolist enabled). - A failed nightly update: read the most recent file in
/var/cpanel/updatelogs/.
If untrusted users were on the server while it was vulnerable
The vendor has not published indicators of compromise for this CVE, so there is no specific log line that proves or disproves exploitation. What follows is general cross-account hygiene for a shared server after a critical cross-tenant flaw. Treat findings as leads to investigate, not as proof.
1. WordPress administrators and settings
For every site, list administrator users and compare siteurl and admin_email with what the customer expects. The loop below only covers each account’s main public_html; addon domains, subdomains and custom document roots live elsewhere. To cover every document root cPanel knows about, feed the loop from awk -F'==' '{print $5}' /etc/userdatadomains | sort -u instead, or work from the site list in WHM under WP Toolkit:
for d in /home/*/public_html; do
[ -f "$d/wp-config.php" ] || continue
u=$(stat -c %U "$d")
echo "== $u $d"
sudo -u "$u" -- wp --path="$d" option get siteurl
sudo -u "$u" -- wp --path="$d" option get admin_email
sudo -u "$u" -- wp --path="$d" user list --role=administrator --fields=user_login,user_email,user_registered
done2. Database users and grants
No account’s database user should have privileges on another account’s databases. On cPanel, database and database-user names start with the account’s prefix (user_), so a grant where the grantee’s prefix differs from the database’s prefix is a lead. Start with database-level grants:
mysql -e "SELECT grantee, table_schema, privilege_type FROM information_schema.schema_privileges ORDER BY grantee" | lessDatabase-level grants are only part of the picture. A user with global privileges, table or column grants, or a role can reach data that the query above does not show, so review those too:
mysql -e "SELECT grantee, privilege_type FROM information_schema.user_privileges WHERE privilege_type <> 'USAGE' ORDER BY grantee"
mysql -e "SELECT grantee, table_schema, table_name, privilege_type FROM information_schema.table_privileges ORDER BY grantee"
mysql -e "SELECT grantee, table_schema, table_name, column_name, privilege_type FROM information_schema.column_privileges ORDER BY grantee"
mysql -e "SELECT * FROM mysql.roles_mapping" # MariaDB; on MySQL 8 use mysql.role_edgesApart from root and the panel’s own system users, nobody should hold global privileges. For any user that looks wrong, SHOW GRANTS FOR 'user'@'host'; prints the complete set in one place.
3. Recently changed PHP files
Look across accounts for PHP files changed since the vulnerable window began, especially in wp-content/uploads/ where PHP should not exist:
find /home/*/public_html -name '*.php' -newermt '2026-09-01' -path '*uploads*' -lsKnow the limits of this check: it only looks under main public_html directories, only inside uploads paths, and only at files modified after 1 September 2026. Set the date to when the affected WP Toolkit version was first installed on your server, repeat the search for every document root, and remember that an attacker can change modification times, so an empty result is not proof that nothing was planted.
4. Rotate credentials
Rotate WordPress admin passwords, database passwords and API keys stored in wp-config.php for any site where the checks above turn up something you cannot explain.
Reduce the blast radius next time
- Give every WordPress site its own database and database user; never share one across accounts.
- On CloudLinux, keep CageFS enabled so accounts cannot read each other’s files directly. It does not fix flaws in privileged components like this one, but it limits what a compromised account can harvest on its own.
- Monitor component versions, not only the panel build: WP Toolkit, Imunify360 and similar add-ons update separately.
- Keep off-site backups with enough history to restore a site to a point before an incident.
References
This page was last reviewed on 1 October 2026 against both sources. If cPanel updates the advisory, the advisory wins.
WP Toolkit CVE-2026-87900 at a glance
Official documentation: WordPress advanced administration handbook, cPanel & WHM documentation, Linux man pages.
Related guides: WordPress cURL Error 28: Failed to Connect Fixed (Imunify360 and CSF) · Using WP Toolkit Security Risk scores, Smart Update and Vulnerable Components · CSF CVE-2026-65638, 65639, 67402: Critical Patch Guide.
Frequently asked questions
Which WP Toolkit versions are affected by CVE-2026-87900?
WP Toolkit for cPanel 6.11.2-10794 and earlier. It is fixed in 6.11.3 and later.
Is my server patched if cPanel itself is fully updated?
Not necessarily. WP Toolkit is a separate package, so check its own version with rpm -qa | grep -i wp-toolkit (RPM-based servers; use WHM on Ubuntu) and confirm 6.11.3 or later.
How severe is CVE-2026-87900?
The CNA (HackerOne) scores it 9.4 (Critical) under CVSS 4.0, as shown on the NVD record; NVD’s own analysis was still pending on 1 October 2026. It requires a cPanel login but can affect other accounts on the same server.
Are there known indicators of compromise?
The advisory does not publish any. Use general cross-account checks (admin users, database grants, unexpected PHP files) and treat anything unexplained as a lead to investigate.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- WP Toolkit for cPanel 6.11.2-10794 and earlier, fixed in 6.11.3; AlmaLinux, Rocky Linux, CloudLinux
- Last full review
- Next review