Threat Intel

cPanel CVE-2026-58048: Any Tenant With MySQL Access Can Reach Database Root

A cPanel hosting account crossing the privilege boundary to execute SQL as the database administrator.

If you run cPanel with tenants you don't fully trust, patch tonight. CVE-2026-58048 lets any authenticated account holder who can use the MySQL/MariaDB feature execute arbitrary SQL in the database root context, crossing the boundary between a hosting account and the server's administrative database identity. cPanel rates it CVSS 4.0 = 9.4, and warns that depending on OS and database configuration, it "may extend to operating-system-level compromise." It affects all supported cPanel & WHM versions plus WP Squared, and it shipped in a security release that closes two other boundary-crossing bugs alongside it.

This is the operational response, not just the announcement: what actually breaks, which builds fix it, how to check your whole fleet in one loop, and the workaround if you can't patch this hour. Verified against cPanel's advisory and multiple trackers as of August 4, 2026.

What the Bug Actually Is

The root cause is precise and worth understanding, because it explains why the two advisories describing it seem to disagree. The failure sits in cPanel's database-renaming process. When a database is renamed, cPanel creates a replacement database, moves the data, recreates grants and stored code, then drops the original. Per the HackerOne CNA record, SQL mode is not preserved during that rename, which causes SQL to execute in root context.

That's why you'll see it labeled two ways: cPanel's vendor advisory calls it a privilege escalation and never says "SQL injection," while the CVE record classifies it as CWE-89, SQL injection. Both are correct, they're describing one bug from different angles. The advisory doesn't publish the injected input, the affected SQL mode, or the payload, so there's no public exploit detail yet.

⚠️ The open question that matters for multi-tenant operators: cPanel's advisory doesn't clarify whether Team User sub-accounts (the role-limited logins an account owner creates) count as an "authenticated account holder" for this bug if they hold database access. Assume they do until told otherwise, which widens your exposed population beyond primary account holders to every sub-account with MySQL rights.

Who Is Actually Exposed

A Critical rating measures severity, not how many of your servers have someone positioned to use it. That population is set entirely by who holds accounts on the box:

A server whose accounts all belong to one company you control is low urgency, the "attacker" would have to be your own team or someone who's already phished a staff login.
A server selling accounts to strangers (shared hosting, reseller, free-tier) is high urgency, you're handing valid cPanel credentials to untrusted parties by design, and this bug turns any of them with MySQL access into database root.

⚠️ The line isn't clean, though: accounts get phished, resold, or compromised through a vulnerable web app. A "trusted" tenant whose WordPress got popped is now an untrusted tenant with a valid cPanel session. And on consequence, there's no ambiguity, CISA's August 4 enrichment rated the technical impact total, while recording "Exploitation: none" and assessing it non-automatable. That "none" is an August 4 snapshot and says nothing about the days since, so don't read it as safe.

The Patched Builds

Update to one of these or later, matched to your release branch:

Branch	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	138.1.6

⚠️ A documentation trap that will bite people on the 11.118 branch. cPanel's own advisories disagree with each other: the database advisory lists 11.118.0.71 as patched, but the request-smuggling and Exim advisories published in the same release leave the 11.118 branch off their lists entirely. If you're on 11.118, check your installed point release against the database advisory specifically, don't trust the shorter lists on the other two, or you'll think you're unpatched (or patched) when you're the opposite.

Update from WHM, or force the update process from the CLI:

/usr/local/cpanel/scripts/upcp --force

Then verify the build actually moved:

/usr/local/cpanel/cpanel -V

Check Your Whole Fleet in One Loop

⚠️ If you manage more than one cPanel box (and you probably do), the thing you want is to know every server's build at once rather than logging into each. From a management host with SSH access across the fleet, pull the version from every server:

for h in $(cat cpanel-hosts.txt); do printf '%s: ' "$h"; ssh -o ConnectTimeout=5 "root@$h" '/usr/local/cpanel/cpanel -V' 2>/dev/null || echo "UNREACHABLE"; done

That gives you a one-shot inventory of which servers are on a patched build and which aren't. ⚠️ Cross-reference each result against the table above by branch, being on 11.118.0.71 is patched, being on 11.118.0.70 is not, and the point release is the part that matters, not the branch. For the exposure side, on any single server you can list which accounts even hold the MySQL feature (the precondition for this bug):

for u in $(ls /var/cpanel/users); do grep -q 'FEATURE-MYSQL=1\|FEATURELIST=default' "/var/cpanel/users/$u" 2>/dev/null && echo "$u has MySQL feature"; done

That's a rough cut (feature lists can be custom), but it tells you which tenants are in scope on a box you can't patch immediately.

If You Can't Patch This Hour

cPanel's documented workaround is to revoke the MySQL feature from users, which blocks the precondition. Existing databases keep running; users just can't add or remove databases while it's revoked. Do this fleet-wide from WHM's Feature Manager, or disable the MySQL feature on the relevant feature lists.

⚠️ This is a genuine stopgap, not a fix, and it has a real cost: any tenant workflow that provisions databases (a customer installing a new app, an automated deploy) breaks until you restore the feature. Weigh that against your tenant trust level, on a single-company server it's overkill; on a stranger-selling shared box where you can't patch for hours, it's the right call. Patch as soon as your change window allows and restore the feature.

The Other Two in the Same Release

The security release closes two more boundary-crossing bugs. Patching for CVE-2026-58048 fixes these too, but know what you're closing:

CVE-2026-58047 (CVSS 5.6), HTTP request smuggling in cpsrvd, the daemon serving the cPanel/WHM interfaces. Under limited conditions an unauthenticated remote attacker can manipulate responses delivered to other users on the same server, and per the CNA record, credentials could leak as a result. ⚠️ If patching has to wait, the workaround is to disable backend connection reuse by setting cpsrvd_keepalives_disabled=1 in /var/cpanel/cpanel.config and restarting cpsrvd:

echo 'cpsrvd_keepalives_disabled=1' >> /var/cpanel/cpanel.config && /usr/local/cpanel/scripts/restartsrv_cpsrvd

⚠️ Cost: this forces a new TCP and TLS connection per request on ports 2083, 2087, and 2096, which raises latency and CPU on busy servers. Fine as a temporary measure, revert it after patching. cPanel credits Vincent55 Yang with both cpsrvd and database CVEs.

The Exim advisory (GCVE-25-2026-07-45-3), a local user's .forward file can trigger unsafe string expansion in the redirect router under certain pipe-transport configs. Under cPanel's default configuration the expansion runs as the cPanel user, which cPanel says may allow privilege escalation from Team User sub-accounts. Exim 4.99.5 removes the vulnerable expansion and also fixes a High-severity directory traversal via queue-name arguments (GCVE-25-2026-07-45-1) that can read files outside the spool and be used for privilege escalation. Exim's own advisory notes exploitation of the .forward issue requires a specific stack: a redirect router providing .forward handling, an accessible pipe transport, force_command enabled on it, and execution as a privileged user.

This Is a Pattern, Not a One-Off

⚠️ Worth stepping back: this is the third serious cPanel privilege-boundary bug in a few months. April 2026 brought CVE-2026-41940, a CRLF-injection auth bypass in cpsrvd that let an unauthenticated attacker forge a user=root session, and CVE-2025-66429, a Team Manager directory traversal enabling root privilege escalation. The recurring theme is cPanel's privilege boundaries (account-to-root, tenant-to-tenant, sub-account-to-account) being crossable through the control plane. If you operate cPanel at scale, treat the WHM update channel as a standing high-priority patch source, not a monthly-window nicety, and build the fleet-version check above into a scheduled job so you find unpatched boxes before an advisory tells you they were exploitable.

This is the same tenant-isolation-boundary concern that runs through every shared-hosting compromise I've worked, and the forensic discipline for "did a tenant already use this" is the same as any multi-tenant incident: check the signals a compromise leaves early, and if you find evidence of database-root abuse, work the timeline before you clean, because a tenant who reached database root may have written OS-level persistence. The broader "why shared servers get compromised and how to remediate" walkthrough is in why Linux servers get compromised.

Bottom Line

CVE-2026-58048 turns any cPanel tenant with MySQL access into database root, potentially into OS root, and the exposed population is exactly however many accounts you've handed to people you don't fully control. Patch to the build matching your branch (checking the point release, and double-checking 11.118 against the database advisory specifically), run the fleet-version loop to find stragglers, and if you can't patch a stranger-facing box this hour, revoke the MySQL feature as a stopgap and accept the provisioning breakage. CISA says no known exploitation yet, but "yet" is doing a lot of work in that sentence, and this is the third cPanel privilege-boundary bug this year. Treat it as patch-now.