Most security advice assumes you can act on it. Patch this, rotate that, change the setting. The advice we are about to give you is different, because the thing that needs patching is not yours and you cannot touch it.

If your website sits on shared hosting, which for most small businesses it does, then your site is one account among dozens or hundreds on a physical server you have never seen. You have a cPanel login. So does everyone else on that machine. The security boundary that keeps their files out of your files, and both out of the operating system, is enforced by the control panel software. On Monday night cPanel released a fix for a flaw in that software which, according to its own advisory, lets any logged-in account holder run code as root.

Root on that server is everything on that server. Every site, every database, every mailbox, every backup.

Everything below was checked on September 23, 2026. Where we could reach a primary source we did, and we say which source. Where we could not, we say that too, and there is more of that than usual this time, for reasons that turn out to be part of the story.

What shipped

cPanel publishes what it calls a Targeted Security Release, a build that exists to carry security fixes and nothing else. One went out on September 22, 2026.

We did not take that from an article. Every supported branch of cPanel has a change log on the vendor’s documentation site, and all of them were updated on the same day. The newest entry on each reads, in full:

[Security] Targeted Security Release

That is the entire entry. No description, no CVE, no severity. The builds are:

Branch Build Change log date
11.110 (LTS) 110.0.145 2026-09-22
11.134 (LTS) 134.0.57 2026-09-22
11.136 (STABLE) 136.0.41 2026-09-22
11.138 (RELEASE, CURRENT, EDGE) 138.0.8 2026-09-22

The build metadata confirms the timing. The build.json file that ships inside 11.138.0.8 records the compile time as Mon Sep 21 15:12:32 2026 and the type as production, so it was built Monday afternoon and promoted the following day.

The three flaws

cPanel assigned three CVE identifiers. We are reporting them as they have been reported, and flagging clearly that we could not read cPanel’s own advisory text, which we come back to below.

CVE-2026-87899, described as critical, is in the CalDAV and CardDAV service. That is cpdavd, the daemon that serves calendars and contacts to mail clients. A logged-in account holder can use it to execute code as root. cPanel gives the affected range as version 120 and later, and no temporary workaround.

CVE-2026-87900, described as high, is in the WP Toolkit plugin, the thing your host uses to install and manage WordPress for you. A logged-in user can modify databases belonging to other accounts. Fixed in WP Toolkit 6.11.3; affected in 6.11.2-10794 and older.

CVE-2026-68490, described as medium, is in the same CalDAV and CardDAV service and is read-only: a local user can read other accounts’ calendar events and contacts.

All three are credited to the researcher Ali Mustafa, who publishes as rz1027, with a collaborator on some of them. That name matters in a moment.

One thing we did verify ourselves, because it is checkable: as of today, none of these three identifiers exists in the National Vulnerability Database or in the CVE Program’s own record store. We queried both directly. CVE-2026-87899, CVE-2026-87900 and CVE-2026-68490 all return “does not exist.” So there is no published CVSS score to quote, and we are not going to invent one. The severity words above are cPanel’s, relayed.

What we went looking for

The advisory says version 120 and later is affected, and lists fixed builds for the 134, 136 and 138 lines plus WP Squared. Those two statements do not cover the same ground. Versions 120, 122, 124, 126, 128, 130 and 132 all fall inside “120 and later” and none of them is in the fix list.

cPanel is unusual among vendors in that its entire distribution channel is public and unauthenticated. httpupdate.cpanel.net serves the file tree that every cPanel server in the world syncs from, with directory listings and timestamps. You can read it with curl. So rather than reason about what should have happened, we went and looked at what did.

The manifest

Every cPanel server periodically downloads TIERS.json, which maps each release tier to the build it should be running. It is the file that decides what upcp installs. Here is its state this afternoon:

curl -sI https://httpupdate.cpanel.net/cpanelsync/TIERS.json
# last-modified: Tue, 22 Sep 2026 14:56:35 GMT

Refreshed at 14:56:35 UTC on September 22, which is the moment the fix became the thing servers would install. The relevant entries, abridged:

"11.110": [{ "build": "11.110.0.145", "is_lts": 1, "is_security": 1 }],
"11.126": [{ "build": "11.126.0.78",  "is_lts": 1, "is_security": 1 }],
"11.130": [{ "build": "11.130.0.26" }],
"11.132": [{ "build": "11.132.0.35" }],
"11.134": [{ "build": "11.134.0.57", "is_lts": 1, "is_security": 1, "named": ["lts"] }],
"11.136": [{ "build": "11.136.0.41", "is_security": 1, "named": ["stable"] }],
"11.138": [{ "build": "11.138.0.8",  "is_security": 1, "named": ["current","edge","release"] }]

Two things jump out. The 11.110 branch carries the same is_security marker as the three branches in the advisory. And so does 11.126, whose build number has a suspiciously low tail.

The file tree

The manifest tells you what a server is supposed to install. The directory listing tells you when that build was actually put there. Every build gets a folder, and the folder carries a timestamp.

curl -s https://httpupdate.cpanel.net/cpanelsync/11.138.0.8/
# cpanel/     22-Sep-2026 14:38
# build.json  21-Sep-2026 20:23

Run that across the branches and the picture is unambiguous:

Build cpanel/ directory synced Age today
11.134.0.57 22-Sep-2026 14:35 yesterday
11.136.0.41 22-Sep-2026 14:37 yesterday
11.138.0.8 22-Sep-2026 14:38 yesterday
11.110.0.145 22-Sep-2026 14:44 yesterday
11.126.0.78 29-Jul-2026 16:05 56 days
11.130.0.26 19-May-2026 23:33 127 days
11.132.0.35 19-May-2026 23:32 127 days

Finding one: a fourth branch got the fix and is not in the advisory

The four security branches synced inside a nine-minute window, 14:35 to 14:44 UTC. 11.110.0.145 is in that window and is not in the published fix list.

If you run 11.110, which is cPanel’s long-term support release and is on Extended Lifecycle Support through January 1, 2027, and you read the coverage of this advisory, you would conclude that your branch was not fixed and possibly that it was not affected. Neither reading is safe. The correct build for you is 11.110.0.145, and it went out at the same time as everyone else’s.

We should be precise about what we have proved here. We have proved that 11.110.0.145 is a Targeted Security Release, that its change log entry is word for word identical to the other three, and that it was pushed to the mirror in the same nine-minute batch. We have not opened the build and diffed cpdavd. It is a strong inference, not a demonstration, and we are labelling it as one. The practical advice does not change either way: 110.0.145 is the newest build on your branch and it is flagged security, so install it.

There is corroboration in the record for the previous round. The CVE Program record for CVE-2026-67401, the EmailTrack SQL injection from two weeks ago, names its fixed builds explicitly, and 11.110.0.143 is one of them, alongside 11.134.0.55, 11.136.0.39 and 11.138.0.4. So 11.110 was in scope for the September 8 release and received a fix that reporting at the time also tended to omit. The pattern is not new.

Finding two: branches 120 through 132 are frozen, and they are not empty

This is the part that matters most, and it is the part nobody is writing about.

11.130.0.26 and 11.132.0.35 were both pushed to the mirror on 19 May 2026 and nothing has been published for either branch since. That is one hundred and twenty seven days. 11.126.0.78 was pushed on 29 July 2026, fifty six days ago.

These branches were not always frozen. In May, cPanel was still shipping fixes to all of them. The CVE Program records are explicit about it. For CVE-2026-29201, an arbitrary file read, the named fixed builds were 11.136.0.9, 11.134.0.25, 11.132.0.31, 11.130.0.22, 11.126.0.58, 11.124.0.37, 11.118.0.66 and 11.110.0.117. Eight branches. For CVE-2026-29205, a pre-authentication arbitrary file read as root in that same cpdavd daemon, the list included 11.132.0.32, 11.130.0.23 and 11.126.0.59.

Then the coverage narrowed. By CVE-2026-65643 on August 27, an eval injection giving remote authenticated users code execution as root, the record’s affected range reads “from 11.112.0.0 up to but not including 11.134.0.53.” A server on 11.132.0.35 is squarely inside that range, and the nearest named fix is on a different major version. By CVE-2026-67401 on September 8, the fix list was down to five builds across four branches.

So a server still running 11.132.0.35 today is, by the vendor’s own published affected ranges, carrying at minimum:

  • CVE-2026-65643, authenticated remote code execution as root
  • CVE-2026-67401, SQL injection to code execution as root, scored 9.9 by cPanel on CVSS 3.1
  • CVE-2026-87899, authenticated code execution as root, in the affected range “120 and later”

with no fix available on its own branch for any of them. The remedy is a major version upgrade, which is a maintenance window, a compatibility question and a scheduling negotiation rather than an overnight patch. That is exactly the kind of work that slips.

Finding three: the manifest still calls 11.126 security-maintained

Look again at the TIERS.json excerpt. The 11.126 entry carries is_security: 1, the same flag as the four branches that received a build yesterday, and an expires value of 1814313601, which is June 30, 2027.

Now compare that against cPanel’s own lifecycle documentation, the page titled Product Versions and the Release Process, last modified 2026 July 8. Its table of current releases lists exactly four entries: 110 (LTS), 134 (LTS), 136 and 138. Version 126 is not in it. And the page is unambiguous about what that means, verbatim:

When a release of cPanel & WHM no longer exists in any tier and reaches EOL, it becomes unsupported. Unsupported versions don’t receive security updates or bug fixes.

So the documentation says 126 is done, and the machine-readable manifest that servers actually consume says 126 is a security-flagged LTS tier good through the middle of 2027.

One honest qualification, because we do not want to overstate this. cPanel does not publish a schema for TIERS.json, so the meaning of is_security is our reading, not a documented fact. What we can say is that the flag appears on exactly five tiers, that four of the five received a security build yesterday within nine minutes of each other, and that the fifth has not received one in eight weeks. Whatever the flag is meant to signal, 11.126 is not currently getting what the other four are getting.

A second qualification in the same spirit: the lifecycle table gives version 136 an approximate end of life of August 2026, which has already passed, while 136 is still the branch named stable in the manifest and still received yesterday’s release. The page calls its dates approximate and has not been touched since July 8. Treat the table as a guide to intent, not a live feed. The mirror is the live feed.

Why the new hourly auto-patch does not rescue any of this

There is a genuine improvement buried in this year’s change logs, and it deserves credit before we explain its limit. cPanel added an expedited security update path. From the 138 change log, verbatim:

Implemented CPANEL-53412: WHM servers now apply current-major security releases within an hour by default, independent of the normal update schedule. Control this with the new Security Updates option in WHM Update Preferences or the SECURITY_UPDATES key in /etc/cpupdate.conf.

That is a real change and a good one. A host on a supported branch who has left the defaults alone should have picked up yesterday’s build within about an hour of 14:56 UTC, without anybody being paged.

Read the second word of the quote carefully, though. Current-major. The mechanism applies security releases within the major version the server is already on. On 11.132 there is no current-major security release, because the last thing published for 11.132 was in May. So the hourly check runs, finds nothing to apply, and correctly does nothing, forever. The server is not misconfigured and nothing is broken. The automation is working exactly as designed on a branch that has been left behind, and the effect of it working is silence.

This is the same shape as the problem we documented last week on the Acronis backup plugin, where DirectAdmin’s Plugin Manager reported everything was up to date while serving a build from October 2025. In both cases the update machinery is honest and the answer it gives is reassuring and wrong. An update system that says “nothing to install” is indistinguishable, from the operator’s chair, from one that says “you are fully patched.”

Why “authenticated” is not the comfort it sounds like

Every one of these flaws requires a login. On most software that materially reduces the risk. On shared hosting it does close to nothing, for a reason that is structural rather than incidental: the product being sold is the credential. A hosting company’s entire business is issuing cPanel accounts to strangers who paid with a card. Anyone can have one, today, for a few dollars, on the machine of their choosing if they shop by IP range. Reseller hosting multiplies this, because one reseller account can create many more.

cPanel itself scores the flaws accordingly. CVE-2026-67401 was rated 9.9 with the vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. The PR:L is the login requirement, and it barely dents the score, because S:C records that the impact escapes the account it started in and reaches the whole system. That is the correct way to model a shared host, and it is the model most people carry in their heads for a dedicated server and then apply, wrongly, to a shared one.

We made a similar argument about remote monitoring tools being a single point of compromise across every client an MSP touches. Shared hosting has the same geometry. One box, many businesses, one privilege boundary between them.

The year cPanel has had

It is worth zooming out, because a single advisory is a headline and a pattern is a decision.

Since the end of July, cPanel has published Targeted Security Releases on July 29, August 27, September 8 and September 22, plus security hardening builds on August 24 and September 10. That is four security releases in eight weeks, with gaps of 29, 12 and 14 days, and the interval is shortening.

Then there is the catalogue. We pulled CISA’s Known Exploited Vulnerabilities list directly today, version 2026.09.22, 1,721 entries, released at 19:02 UTC yesterday. Four entries in it belong to the cPanel ecosystem:

CVE Product Added Notes
CVE-2026-41940 cPanel & WHM, WP2 2026-04-30 ransomware use: Known
CVE-2026-48172 LiteSpeed cPanel Plugin 2026-05-26
CVE-2026-54420 LiteSpeed cPanel Plugin 2026-06-15
CVE-2026-87886 Acronis Backup for cPanel and Plesk 2026-09-16 forensic triage required

None of yesterday’s three is in that catalogue, and as of today there is no public report of exploitation. We want to be careful about how much weight that carries. CVE-2026-41940 was disclosed by cPanel on April 28 and added to KEV, already flagged for known ransomware campaign use, on April 30. Two days. “No exploitation reported” describes the last twenty four hours; it is not a property of the vulnerability.

The other thing the KEV entries show is that the control panel is not the only exposure. Two of the four are a caching plugin and a backup plugin, both bolted onto cPanel by hosts to add features. We wrote up the Acronis one on Friday and the punchline there was that the plugin’s own update channel was serving a vulnerable build while reporting success. The control panel layer of shared hosting, taken as a whole, has produced four actively exploited vulnerabilities in five months.

What you can actually do

You are the customer, not the administrator. You cannot run upcp. So the useful actions are the ones available from your side of the line.

1. Find out what version you are on. Log in to cPanel. The version number is displayed in the interface, usually in the sidebar or the footer, in the form 11.138.0.8 or sometimes just 138.0.8. Write it down. If it is not visible, your host has hidden it, and question three below becomes the important one.

2. Compare it against the current builds. These are the numbers as published in cPanel’s own manifest this afternoon. You can check them yourself, from anywhere, without an account:

curl -s https://httpupdate.cpanel.net/cpanelsync/TIERS.json | grep -A2 '"11.13'

What you want to see on your server is one of:

11.110.0.145   (LTS, extended support to January 1 2027)
11.134.0.57    (LTS)
11.136.0.41    (STABLE)
11.138.0.8     (RELEASE / CURRENT)

Plus WP Toolkit at 6.11.3 or later if your host uses it, which most do if they offer one-click WordPress.

3. If the number starts with 120, 122, 124, 126, 128, 130 or 132, stop and read it again. That is not a patching question. That branch has had no build in eight to eighteen weeks, and by cPanel’s own published affected ranges it is carrying unpatched root-level flaws whose fixes exist only on a newer major version. This is a “when are you upgrading, and what is the plan if you are not” conversation.

4. Send your host these four questions. Short, specific, answerable, and the answers are a decent proxy for whether anyone is minding the store.

  1. Which cPanel & WHM build is the server hosting our account currently running? Please give the full build number, not the major version.
  2. Did that server receive the Targeted Security Release published on September 22, 2026, and at what time?
  3. Is WP Toolkit on that server at 6.11.3 or later?
  4. Is the Security Updates option in WHM Update Preferences set to apply security releases automatically?

A host that answers all four inside a business day is a host that is paying attention. A host that answers with “our servers are fully patched” and no build number has told you nothing, and you should ask again. A host that cannot tell you which build it is running has answered the question anyway.

Update, September 24, 2026: the CVE records landed, and they settle two of the three findings

Twenty four hours on, three of the gaps this article recorded have closed. We re-ran every check.

The CVE records are published. All three identifiers went live in the CVE Program record store at 19:52:47 UTC on September 23, about thirty hours after the release. The severity words this article relayed now have numbers behind them, on CVSS 4.0:

CVE Score Vector Description as published
CVE-2026-87899 9.4 critical AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H “Execution with unnecessary privileges in cPanel allows remote authenticated users to execute arbitrary code with root privileges.”
CVE-2026-87900 9.4 critical same “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.”
CVE-2026-68490 8.2 high AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N “Incorrect permission assignment allows local users to obtain sensitive CalDAV/CardDAV information belonging to other accounts.”

Two corrections to what was reported at the time, ours included, since we relayed it. The WP Toolkit flaw is argument injection, and it is not limited to modifying other accounts’ databases: the record says arbitrary file read and code execution across customer accounts. And the fixed WP Toolkit build is 6.11.3-10850, not simply 6.11.3, which resolves the open question in the section below. Note also that both SC:H/SI:H/SA:H on the first two, the CVSS 4.0 way of recording that the damage crosses out of the account it started in, which is the same modelling point the shared hosting section above makes.

Finding two is now confirmed by the vendor’s own machine-readable data. The affected range in the CVE-2026-87899 record is published as three intervals, and here is the first one verbatim:

{ "version": "11.120.0.0", "status": "affected", "lessThan": "11.134.0.57", "versionType": "semver" }

Branches 11.126, 11.130 and 11.132 all sit inside that interval. The record names no fixed build for any of them. This is no longer our inference from a directory listing: the vendor’s own structured record says those branches are affected and lists nothing that fixes them.

Finding one is unchanged, and it just happened again. The records still make no mention of 11.110 in any capacity, neither affected nor fixed. Meanwhile cPanel shipped a second batch on September 23, and the sync timestamps on the public mirror show the same shape as the first:

Build cpanel/ directory synced
11.110.0.147 23-Sep-2026 19:33
11.134.0.59 23-Sep-2026 19:36
11.136.0.43 23-Sep-2026 19:38
11.138.0.10 23-Sep-2026 19:41

Four branches, an eight-minute window, TIERS.json refreshed at 19:45:42 GMT behind them, and 11.110 in the batch again. That is the second consecutive release in which the branch that is absent from the published paperwork is present in the distribution channel. If you run 11.110, the current build is now 11.110.0.147.

Finding three got sharper, and the undocumented flag explained itself. This article flagged that is_security on the 11.126 tier was our reading of a field with no published schema. Today’s manifest answers it by elimination. The flag has been cleared from 11.110, 11.134, 11.136 and 11.138, the four branches that received yesterday’s build. It now appears on exactly one tier in the entire file:

"11.126": [{ "build": "11.126.0.78", "expires": 1814313601, "is_lts": 1, "is_main": 1, "is_security": 1 }]

So is_security looks like a transient marker, set on a tier during a security release window and cleared once the build has propagated. Which makes 11.126 the one tier still flying a flag from a release it never received. Its build is still 11.126.0.78 from 29 July, now 57 days old. 11.130.0.26 and 11.132.0.35 are still dated 19 May, now 128 days.

Nothing in the action list changes. The four questions are the same four questions, and the build numbers to check against have each moved up by one release.

What we could not verify

Recording this properly, because it is unusually long this time and some of it is load-bearing.

cPanel’s own advisory text. We could not read it. security.cpanel.com returned a Cloudflare 522, an origin timeout, on three consecutive attempts between 13:16 and 13:18 UTC today from a US East edge. support.cpanel.net, where the advisory articles actually live, served a Cloudflare interactive challenge to every non-browser client we tried, including a headless browser. Both pages very probably load fine in an ordinary browser, and we are not claiming cPanel’s advisory is unavailable to humans. We are recording that on the day after a root-escalation release, the vendor’s advisory is not reachable to any automated check, which is how most monitoring, most feed readers and most vulnerability tooling would try to reach it.

The CVE records. On publication day all three identifiers were absent from both NVD and the CVE Program record store, so the severity ratings in this article were cPanel’s own words, relayed through reporting. The records went live at 19:52:47 UTC on September 23; see the September 24 update above for the scores.

WP Toolkit 6.11.3. We could not find a WebPros-published change log confirming that build. The version number comes from the advisory as reported. We did confirm that cPanel’s plugin repository metadata in TIERS.json gives cpanel-plugins a date stamp of 2026-09-03.1, which predates the release, but we do not know enough about how that field is maintained to draw a conclusion from it, so we are not drawing one.

WP Squared 11.138.1.11. The advisory names it as the fixed build for the WP Squared product. WP Squared’s own change log, which we fetched directly and which was itself last modified at 16:04 UTC on September 22, the same afternoon, has no 138.1.11 entry. Its newest entry is 138.1.10, released September 18. We are not going to guess whether the build exists and the change log lags, or the reverse. If you run WP Squared, check your installed version rather than the change log.

Whether 11.110.0.145 contains this specific fix. Inference from identical change log wording and same-batch sync timing, as set out above. Not a demonstration.

The meaning of is_security. Our reading of an undocumented field.

Market share. We wanted to give you a figure for how much of the web runs on cPanel and we could not get one from a source we trust, so there isn’t one in this article.

The short version

On September 22 cPanel fixed a flaw that lets any hosting customer take root on a shared server. If you are on 110, 134, 136 or 138, the fix exists and your host either has it or is an hour away from it. If you are on anything between 120 and 132, the fix does not exist for you and has not for months, your control panel’s automatic security updates are running correctly and finding nothing, and the only real answer is a major version upgrade.

You cannot install any of it. What you can do is find out your build number and ask four questions, and the quality of the answers will tell you more about your hosting than any uptime page will.

If you would rather not have this conversation every six weeks, that is a reasonable position and it is usually the real conclusion people reach after reading something like this. Moving a small business site off shared hosting is less dramatic than it sounds, and we have written about what a Toronto small business site actually costs to build and run and about choosing between Astro, Next.js and WordPress for the underlying decision. A static site on a CDN has no cPanel, no cpdavd, no neighbours and no control panel to escalate through. If you want us to look at where your site currently lives and what it would take to move it, get in touch.

Sources

  • cPanel & WHM 138 Change Log, docs.cpanel.net, last modified 2026 September 22, for build 138.0.8 dated 2026-09-22, the verbatim Targeted Security Release entries, the release dates of 138.0.1 through 138.0.7, and the full text of CPANEL-53412 on current-major hourly security updates
  • cPanel & WHM 136 Change Log, for build 136.0.41 dated 2026-09-22
  • cPanel & WHM 134 Change Log, for build 134.0.57 dated 2026-09-22
  • cPanel & WHM 110 Change Log, for build 110.0.145 dated 2026-09-22, the branch absent from the published fix list
  • cPanel & WHM 126 Change Log, last modified 2026 August 18, newest entry 126.0.78 dated 2026-07-29
  • cPanel & WHM 132 Change Log, last modified 2026 May 20, newest entry 132.0.35
  • Product Versions and the Release Process, docs.cpanel.net, last modified 2026 July 8, for the release tier definitions, the four-row current release table, the version 110 Extended Lifecycle Support exception, and the verbatim statement that unsupported versions do not receive security updates
  • TIERS.json, cPanel update mirror, fetched today, last modified Tue, 22 Sep 2026 14:56:35 GMT, for the per-tier build assignments, the is_security and is_lts flags, the 11.126 expiry of 2027-06-30 and the cpanel-plugins repository date stamp
  • cPanel sync mirror directory listings, fetched today, for the per-build publication timestamps in the table above and for the complete list of published 11.126, 11.130 and 11.132 builds
  • CVE-2026-67401, CVE Program record, published 2026-09-09, for the 9.9 CVSS 3.1 score and vector, the EmailTrack SQL injection description, and the fixed build list including 11.110.0.143
  • CVE-2026-65643, CVE Program record, published 2026-09-01, for the eval injection description, the 8.7 CVSS 4.0 score, the affected range from 11.112.0.0 to 11.134.0.53, and the credit to Ali Mustafa
  • CVE-2026-29201 and CVE-2026-29205, CVE Program records, published May 2026, for the eight-branch and nine-branch fixed build lists that establish how much wider the coverage used to be, and for the earlier pre-authentication root file read in the same cpdavd component
  • Known Exploited Vulnerabilities Catalog, CISA, catalog version 2026.09.22, 1,721 entries, released 2026-09-22T19:02:09Z, pulled today, for the four cPanel ecosystem entries, the “Known” ransomware flag on CVE-2026-41940, its April 30 addition two days after disclosure, and the confirmation that none of the three new CVEs is listed
  • WP Squared Changelog, docs.wpsquared.com, last modified 2026-09-22 16:04:31 GMT, whose newest entry is 138.1.10 from September 18 with no 138.1.11
  • New cPanel Flaw Lets a Hosting Account Run Code as Root, Take Full Server Control, The Hacker News, September 22, 2026, for the three CVE identifiers, the severity words, the affected and fixed version strings, and the credit to Ali Mustafa and collaborator