cPanel CVE-2026-58048: in shared hosting, your neighbour sets the risk

On 31 July two cPanel & WHM flaws were published. The one taking the headlines is CVE-2026-58048, a 9.4 out of 10: by renaming a database, an ordinary customer on the server could end up executing SQL in the root context. But the number that actually describes the problem is not the 9.4. It sits at the end of the vector, where almost nobody looks: SC:H/SI:H/SA:H.

We are writing about this because it is a textbook case of something that gets discussed little and suffered plenty: on a shared machine, your attack surface includes people you did not choose. This is not an attack on shared hosting — we get to that question later, and the answer is not the expected one. It is that the threat model is different, and this pair of CVEs states it in writing with unusual precision.

The flaw, in one sentence from its own record

The official description fits on one line: "Improper preservation of SQL mode when renaming databases in cPanel allows execution of SQL in root context." It is classified as CWE-89, SQL injection, and credited to Vincent55 Yang.

Renaming a database is not an atomic operation. According to cPanel's documentation, as reported by The Hacker News, on rename the system "creates a replacement database, moves the original data, recreates grants and stored code, and then removes the old database". It is a long sequence of SQL the panel runs for you, with its privileges, built from a name you type.

What it takes to get there is the interesting part. The published vector says PR:L: low privileges, not none. You need a valid account on the server and permission to use the MySQL or MariaDB feature. Put another way: on a shared hosting server, the attack's prerequisite is a signup form. And UI:N: nobody needs to click anything.

The tail of the vector: where CVSS 4.0 says "this leaves the building"

The full vector is 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. The first three impacts (VC, VI, VA) describe the vulnerable system. The last three (SC, SI, SA) describe the subsequent system: whatever sits on the other side of the failing component.

That split is the least-used and most informative thing CVSS 4.0 added. The specification asks for the opposite by default: "when a vulnerability does not have impact outside of the vulnerable system, assessment providers should leave the subsequent system impact metrics as NONE". Here they are not none; all three are High. Where one system ends and the next begins is a judgement, not a fact — the specification itself gives the example of a database used solely by a smart speaker, which is therefore part of that speaker — so the vector alone, in the abstract, does not settle the argument. Except the vendor settles it without metrics: of this flaw it says "this may extend to operating-system-level compromise".

And on a shared machine, "the subsequent system" has a name. It is the accountancy firm's CRM two doors down, the neighbouring manufacturer's shop, and your website. The word "subsequent" is very cold for what it describes: the subsequent system belongs to somebody else.

The 5.6 CVE that says it even more plainly

The same day, the same researcher and the same batch of patches brought CVE-2026-58047: "HTTP Smuggling in cPanel allows potential leak of credentials", classified as CWE-444, in cpsrvd, the daemon serving the cPanel and WHM interfaces. It scores 5.6: medium. Nobody opens an emergency window for a 5.6.

Now its vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:H/SI:H/SA:L. Read the whole thing, which is what this article is about. Unauthenticated (PR:N), but with two brakes the vector itself declares: AT:P, deployment conditions the attacker does not control are required, and UI:P, somebody has to be using the panel at that moment. The Hacker News sums it up in three words: under limited conditions. And now the impacts: low on the vulnerable system (VC:L/VI:L), high on the subsequent one (SC:H/SI:H). Translated: it does little damage where it lands and a lot to a third party — whoever receives the poisoned response, which is another user of the same server.

Here the vendor spared us the decision: both records list exactly the same versions and the same batch of builds closes both flaws. But they arrive separately often enough, and then a patching policy that filters on "criticals" takes the 9.4 and leaves the 5.6 for next month — and the 5.6 is the one that needs no customer account. A single severity number blends "how hard is it to reach" with "how much damage does it do"; in multi-tenancy those two do not travel together, and sorting the patch queue by the big number sorts it by the first when what worries you is the second.

What the advisory does NOT say (and is worth not inventing)

Time to take the temperature down. CISA's enrichment on both CVEs, dated 31 July, records exploitation: none and automatable: no. Neither is, as of today, in the known exploited vulnerabilities catalogue. There is no campaign under way.

With a nuance that is often misread: "automatable: no" does not mean "hard". It means the attacker cannot sweep the internet firing the same payload blindly, because they first need an account on that server. On a hosting panel, that prior step has a list price. It is an economic barrier, not a technical one, and economic barriers drop as the target gains value. On technical impact, by contrast, CISA's record hedges nothing: it classifies it as total for the 9.4.

What to check this week

• Which build you are on. The fixed versions are 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48 and 11.136.0.32, plus 11.138.1.6 for WP Squared. Five live cPanel branches at once, and the same batch closes both CVEs: that is how spread out the installed base is across the LTS, STABLE, RELEASE and CURRENT tiers.
• That the security clock is running. The good news first: by default, the system applies security updates for your current major version every hour via a cron job, and it does so even if you disable version updates or set them to run manually. The small print, in the same sentence of the WHM documentation, is what matters: that cron does not run if you set the server to use a specific version. Which means the machine somebody pinned to a build years ago so that "nothing would break" is precisely the one not patching itself. Verifying that takes a minute.
• If you cannot update today, the mitigation for the 9.4. Revoke the "MySQL" feature from cPanel accounts. The note itself scopes it honestly: "this will not disable existing databases but just prevent adding/removing". Sites keep working and the attack path disappears.
• And the one for the 5.6, which almost nobody mentions. Disable backend connection reuse with cpsrvd_keepalives_disabled=1 in /var/cpanel/cpanel.config. It is not free: it forces a fresh TCP and TLS connection per request on ports 2083, 2087 and 2096, meaning more latency and more CPU on busy servers. If this post has convinced you that the 5.6 is the one that affects you most as a neighbour, this is the box that proves it.
• The question almost nobody can answer. Which server is your website on, and who else is on it? That is not rhetorical: in plenty of companies the hosting was signed eight years ago, it is managed by the agency that did the design, and nobody inside has panel access. If nobody can answer, that is the finding of the day — not the CVE.

We have asked that last question here before from another angle, when we wrote about who actually maintains your WordPress. The product changes; the gap does not: the company website is, in many organisations, the only production system with no internal owner.

The uncomfortable part: should you leave shared hosting?

This is where the sales paragraph would go. We are not going to write it, because it would be false. For a great many sites, shared hosting is the right call, and it still would be tomorrow: a static corporate site, a blog, a landing page. Moving them out means paying more to manage more and sleeping exactly as well.

What does change is what you can promise. On shared hosting you do not control the neighbourhood: you do not choose who else has an account, you do not audit their code and you do not decide when the machine gets patched. That is not an anomaly or a vendor failing; it is literally what you are buying when the price is divided by three hundred. The mistake is not signing up for it: the mistake is signing up for it and then promising a customer, or an auditor, an isolation that model never offered.

Our criterion, after years building infrastructure for business applications, fits in one question: what is inside the database? Blog posts? Go ahead. Customers' personal data, orders, medical history or the catalogue with purchase prices? Then isolation stops being a performance question and becomes a question of who you answer to. Once obligations enter the picture — and the list of who falls inside has widened considerably — "it was on shared hosting" is not an answer that survives a supplier questionnaire.

The recurring pattern: the surface you did not choose

A few days ago we wrote about a Rails flaw that actually lived in an image library nobody had consciously chosen. This is the same animal, one floor down: the risk does not come in through the code you commissioned, but through whatever came underneath. There it was a dependency; here it is a neighbour.

And in both cases the useful defence is the same, and it is boring: knowing what you have underneath before somebody publishes a CVE about it. No tool solves that. An inventory does, and an owner.

If you want us to look at where your application really lives, what is in its database and what isolation it needs — or whether it needs none at all, which also happens — that is part of what we do in data and applications; and when the answer involves your own hardware in a data centre, in colocation.

Sources (verified on 7 August 2026): the identifier, the verbatim description ("Improper preservation of SQL mode when renaming databases in cPanel allows execution of SQL in root context"), the CWE-89 classification, the vector 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 scoring 9.4 CRITICAL, the publication date (31 July 2026), the credit to Vincent55 Yang, the affected and fixed versions (11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32 and WP Squared 11.138.1.6) and CISA's SSVC enrichment (exploitation: none; automatable: no; technical impact: total) come from the official CVE-2026-58048 record, assigned by HackerOne as CNA, retrieved from MITRE's API. The same data for CVE-2026-58047 ("HTTP Smuggling in cPanel allows potential leak of credentials", CWE-444, vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:H/SI:H/SA:L, 5.6 MEDIUM, technical impact: partial). That cpsrvd is the daemon serving the cPanel and WHM interfaces, the description of the rename process attributed to cPanel's documentation ("creates a replacement database, moves the original data, recreates grants and stored code, and then removes the old database"), the vendor's sentence "this may extend to operating-system-level compromise", the "under limited conditions" on the second flaw and its mitigation (cpsrvd_keepalives_disabled=1 in /var/cpanel/cpanel.config, forcing a fresh TCP and TLS connection per request on ports 2083, 2087 and 2096, with its latency and CPU cost) all come from the coverage by The Hacker News. The temporary mitigation of revoking the MySQL feature ("this will not disable existing databases but just prevent adding/removing") is recorded there and in Security Affairs. The distinction between vulnerable and subsequent system, the sentence "when a vulnerability does not have impact outside of the vulnerable system, assessment providers should leave the subsequent system impact metrics as NONE" and the example of a database used solely by a smart speaker come from FIRST's CVSS v4.0 specification document. That by default the system applies security updates for the current major version every hour via a cron job, that this cron runs even if version updates are disabled or set to manual, and that it does not run if the server is set to a specific version, come from the WHM update preferences documentation, which is also the source for the tier names. We have reproduced neither flaw: this article is a reading of the public records, the vendor documentation and the cited coverage, and says so. Social image photograph: residential building facade with balconies, rawpixel, public domain (CC0).