cPanel filed two 9.4 criticals and told customers one of them was a database problem

Three advisories, no numbers

cPanel published three security advisories on 22 September 2026. All three were written by the same author, all three credit the same researcher, and all three describe flaws that break the boundary between one hosting customer and another.

The next day, at 20:17 UTC, the matching CVE records appeared. Two of them are scored 9.4, critical. The third is scored 8.2.

None of those numbers appears on the advisories. Neither does the word critical, nor the word high, nor a CVSS vector, nor any severity rating of any kind. An administrator who reads only cPanel's own security pages, which is what most administrators do, has nothing to sort these three by except the prose.

And the prose is where it gets interesting.

Say straight away what this does not establish.

It does not establish that cPanel hid anything. The company is the CNA here, filing through HackerOne, so cPanel itself wrote both the advisory wording and the CVE wording. The fuller description was published by the same organisation, one day later, in the place where a machine will read it.

It does not establish that anyone has been attacked. There is no report of exploitation for any of the three, no entry in the CISA catalogue of known exploited vulnerabilities, and no public proof of concept that I could find.

It does not establish that a CVSS score is the right way to prioritise. It frequently is not.

What it establishes is narrower. On the page a human reads, one of these two 9.4 flaws is described as a database problem. On the record a machine reads, the same flaw is described as arbitrary file reads and arbitrary code execution across customer accounts. Both descriptions come from the same vendor, about the same bug, one day apart.

The same flaw, described twice

CVE-2026-87900 affects WP Toolkit, the component cPanel customers use to install and manage WordPress sites.

Here is cPanel's advisory, in full, under the heading Impact.

Successful exploitation can lead to an authenticated cPanel user being able to perform database modifications in other accounts.

Here is the description in the CVE record that cPanel filed.

Argument injection in WP Toolkit for cPanel 6.11.2-10794 and earlier allows remote authenticated users to read arbitrary files and execute arbitrary code across customer accounts.

Those are not the same sentence. "Perform database modifications in other accounts" describes a data integrity problem inside a database. "Read arbitrary files and execute arbitrary code across customer accounts" describes a full compromise of every other tenant on the machine. The CVSS 4.0 vector filed alongside it agrees with the second reading and not the first: confidentiality, integrity and availability are all marked high, and so are the three subsequent system impact metrics.

The three advisories of 22 September 2026 against the CVE records filed on 23 September. Advisory wording from support.cpanel.net, CVE wording and scores from the National Vulnerability Database.

CVE	What the cPanel advisory tells an administrator	What the CVE record says	Score
CVE-2026-87899	An authenticated account holder can escalate privileges. Code execution as root, full control of the server	Execution with unnecessary privileges allows remote authenticated users to execute arbitrary code with root privileges	9.4 critical
CVE-2026-87900	An authenticated cPanel user can perform database modifications in other accounts	Argument injection allows remote authenticated users to read arbitrary files and execute arbitrary code across customer accounts	9.4 critical
CVE-2026-68490	A local user can read calendars and contacts of other accounts. Does not grant modification. Does not grant root	Incorrect permission assignment allows local users to obtain sensitive CalDAV or CardDAV information belonging to other accounts	8.2 high

Read that table downwards and the pattern is the wrong way round.

The least severe of the three, the read only calendar leak, gets the most precise advisory. It is the only one of the three that tells you what the flaw does not do: it does not grant the ability to modify that data, and it does not grant root access. That is a well written impact statement and cPanel deserves credit for it.

The two scored 9.4 get less. The root escalation is described plainly enough, and its advisory does say full control of the server, which is the important part. The WP Toolkit one is described as a database issue.

Every outlet that covered this followed the advisory rather than the record. That is not laziness. It is what happens when the vendor page is published first, reads authoritatively, and carries no number to argue with.

Why PR:L is the whole story on shared hosting

The CVSS vector on the two criticals is worth reading in full, because two of its letters carry the entire risk.

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

PR:L means low privileges required. On most enterprise software that is reassuring, because it implies the attacker already needs an account, and accounts are given to employees. On a shared hosting server it means something else entirely. A cPanel account is the product. It is what a hosting provider sells, to anybody, for a few pounds a month, usually with automated signup and no identity check. The privilege the attacker needs is the privilege the business exists to hand out.

cPanel's own advisory for the root flaw lists no precondition beyond holding an account. So on a reseller box the population of potential attackers is every current customer, every future customer who signs up this afternoon, and anybody who phishes or buys one set of customer credentials.

SC:H, SI:H and SA:H are the subsequent system impact metrics, new in CVSS 4.0 and routinely ignored. They say that the harm does not stop at the vulnerable component. That is the formal way of encoding what shared hosting people already know: when isolation fails on a box carrying four hundred small businesses, the incident is four hundred incidents.

There is a second audience here that nobody writes advisories for. A small business does not know it is on a shared server. It bought a website. The contract is with an agency, or with a host whose name appears on one invoice a year. When the box is taken over, the small business is not a party to any of the communication that follows, and cannot patch anything, and will not be told which of the three flaws mattered.

If you are that business, the only useful question is whether your provider applied these builds, and the only way to find out is to ask them in writing.

What to patch, and the version problem

The patched builds are specific. The affected range is not.

For both CalDAV and CardDAV issues, cPanel lists the affected versions as v120 or later. That is not a range, it is an open interval running from a release in 2023 to whatever ships next year. It tells an administrator nothing about whether their particular build is exposed, and it cannot be fed into any inventory tool as a comparison. The fixed builds are given precisely, as four separate numbers across four maintenance lines, which is the right level of detail, and the contrast between the two halves of the same table is hard to miss.

WP Toolkit is handled better: 6.11.2-10794 and older, fixed in 6.11.3.

Affected and patched versions, exactly as cPanel states them on the three advisories of 22 September 2026.

Product	Affected	Patched
cPanel and WHM	v120 or later	11.134.0.57, 11.136.0.41, 11.138.0.8, or WP Squared 11.138.1.11, or later
WP Toolkit	6.11.2-10794 and older	6.11.3 or later

What to do, in order

None of this requires believing that cPanel acted in bad faith. The likeliest explanation is entirely ordinary: the support article was written by someone describing the fix, and the CVE record was written by someone describing the vulnerability, and nobody compared the two.

That is precisely why it is worth your attention. If the mismatch had been deliberate it would be rare. Because it was routine, it will happen again, at another vendor, next month.

So here is the question to take into your next patch cycle. Your prioritisation reads vendor advisories, because that is what arrives first and that is what your team subscribes to. How many of the things you deprioritised this year were scored critical somewhere you were not looking?

Key facts