# WP Toolkit CVE-2026-87900: what is affected and how to patch to 6.11.3

Source: https://srvscripts.com/guides/wp-toolkit-cve-2026-87900/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

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.

In short: WP Toolkit CVE-2026-87900 is a critical vulnerability in the WP Toolkit component that cPanel servers use to manage WordPress sites.

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-toolkit
```

On 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'"
done
```

## Update 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 with `dnf 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
done
```

### 2. 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" | less
```

Database-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_edges
```

Apart 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*' -ls
```

Know 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

- [cPanel advisory: CVE-2026-87900 vulnerability in WP Toolkit database creation](https://support.cpanel.net/hc/en-us/articles/43597969409943)

- [NVD: CVE-2026-87900](https://nvd.nist.gov/vuln/detail/CVE-2026-87900)

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

Covers: What the sources say, Who is affected, Check your WP Toolkit version and Update to 6.11.3.

**Official documentation:** [WordPress advanced administration handbook](https://developer.wordpress.org/advanced-administration/), [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [WordPress cURL Error 28: Failed to Connect Fixed (Imunify360 and CSF)](https://srvscripts.com/guides/wordpress-curl-error-28-imunify360-csf/) · [Using WP Toolkit Security Risk scores, Smart Update and Vulnerable Components](https://srvscripts.com/guides/wp-toolkit-security-risk-score/) · [CSF CVE-2026-65638, 65639, 67402: Critical Patch Guide](https://srvscripts.com/guides/csf-cve-2026-65638-patch/).

## 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.