SURIQ
On a shared server, the wall between one hosting account and the machine's administrative database identity is supposed to hold no matter who signs up. cPanel just patched a flaw where that wall came down through an ordinary action: renaming a database. Tracked as CVE-2026-58048 and rated 9.4, it lets an authenticated hosting customer run SQL in the database's root context. On a box with dozens of tenants, that is not one customer's problem. It is every tenant's, because database root reaches far past the account that started the query.
cPanel shipped the fixed builds in late July 2026 as a Targeted Security Release, which we covered on July 29 while the technical details were still withheld. Now the details are public: the record landed in the National Vulnerability Database on July 31. CISA added its own assessment on August 4 and marked exploitation as none and the flaw as non-automatable. That is a snapshot of a quiet week, not an all-clear.
What is CVE-2026-58048?
CVE-2026-58048 is a database privilege escalation in cPanel and WHM, scored 9.4 on CVSS 4.0. When a database is renamed, cPanel does not preserve the SQL mode, and the operation runs in root context. An authenticated account holder can use that to execute SQL with the server's administrative database privileges.
The two disclosures that describe it point at the same result from different angles. NVD classifies it as SQL injection (CWE-89). cPanel's advisory calls it a privilege escalation. Both mean input that should stay inside one account's boundary instead executes as the database superuser. Depending on how the server is configured, that can extend to operating-system-level compromise, because a database running as root is a well-worn path to command execution on the host.
Who is exposed
The precondition is an active hosting login that can reach the MySQL or MariaDB tools in cPanel. On paper that sounds like the risk is a malicious paying customer, which is rare. In practice the exposed population is far larger, and here is the first thing the wire coverage skips: the realistic attacker is not a customer at all, it is a compromised account. Shared-hosting logins get phished, reused, and stolen through vulnerable web apps on a single tenant every day. Any one of those hijacked accounts now has a route from a normal database feature to the identity that underpins the whole server.
One detail is still unsettled and worth watching: reporting notes ambiguity over whether Team User sub-accounts count as authenticated account holders for this flaw. If they do, the reachable population is wider still. Treat that as an open question and patch regardless.
Credit for the report goes to a researcher credited as Vincent55 Yang, who also reported a second issue in the same release, covered below.
Patch to the fixed build before you do anything else
All supported cPanel and WHM versions are affected, along with WP Squared. cPanel shipped fixes across every maintained release series, so the build you patch to depends on the series you run.
If your servers take cPanel updates automatically, confirm they landed rather than assuming it. If you hold updates for a maintenance window, this is the flaw that justifies moving the window up. There is no configuration workaround that closes the rename path without the patch, so account isolation alone will not save you here. Tenant sandboxing on shared hosting is built to contain a well-behaved account, not one that has found a legitimate query path into root.
The exploitation status is a timer, not a reprieve
No public exploit is circulating and CISA rates in-the-wild exploitation as none right now. That is genuinely good news, and it is why this is a patch story and not an incident story. But read the CISA label precisely. Non-automatable means it is harder to spray at internet scale, which buys hours to days, not weeks. Every shared-hosting flaw that reaches root eventually draws attention from the same operators who mine hosting panels for reselling and cryptomining, and a 9.4 with a clear root cause is exactly the kind they reverse from a patch diff.
Shared hosting keeps breaking at the same seam
This is the third time in 2026 we have written up a shared-hosting product where the boundary between a tenant and root gave way. LiteSpeed's cPanel plugin handed tenants root twice this year, and CageFS isolation did not stop it. A public exploit later hijacked unpatched Control Web Panel servers outright. The pattern is consistent: control-panel abstractions sit on top of the server's privileged identity, and every convenience feature that touches that identity is a candidate to leak it. Renaming a database is about as mundane a feature as it gets, which is the point. The dangerous flaws in this class are rarely exotic.
For hosting operators, the operational lesson is to treat the control panel itself as part of the attack surface you monitor, not just the sites it hosts. Tracking which hosts are running an unpatched, known-exploitable build is the first control, and it is the one that turns a 9.4 advisory into a work ticket instead of a surprise.
Patching closes the door. It does not tell you who walked through it
Here is the part the advisory cannot answer for you. Because the abuse runs as legitimate SQL executed in root context, it does not look like an attack in most logs. There is no failed login, no obvious injection string in a request body, no crash. A tenant who renamed a database and rode the root context would leave traces that read like ordinary database administration.
So the patch decision and the detection decision are separate. After you patch, it is worth looking back over database rename events and root-context activity from before the fix landed, especially on servers where account credentials are known or suspected to have leaked. Watch for database users or grants that appeared without a matching account action, unexpected writes to system databases, and new operating-system accounts or scheduled tasks that trace back to a database process. On a multi-tenant box, the blast radius of a single abused account is the whole server, so the hunt is worth the hour even when exploitation is rated none.
Do not forget the second CVE in the same release
The same update fixes CVE-2026-58047, an HTTP request smuggling flaw rated 5.6 that can leak credentials. It is a lower severity and a different mechanism, HTTP request smuggling rather than SQL, but it ships in the identical builds. Treat this as one patch event covering both, not two separate calls. There is no reason to weigh a medium against a critical when the same upgrade closes both.
| Version series | Patched build |
|---|---|
| 11.110 | 11.110.0.137 |
| 11.118 | 11.118.0.71 |
| 11.126 | 11.126.0.78 |
| 11.134 | 11.134.0.48 |
| 11.136 | 11.136.0.32 |
| WP Squared | 11.138.1.6 |