The New cPanel Critical Bug Needs a Valid Login and Still Outscores April's Unauthenticated Root Flaw

What Was Patched

On July 31, 2026, HackerOne published two cPanel advisories on behalf of WebPros. Both were reported by researcher Vincent55 Yang, and both affect cPanel and WHM plus WP Squared.

The one that matters is CVE-2026-58048, rated 9.4 CRITICAL on CVSS 4.0 and classified CWE-89. The description in the CVE record is one sentence:

Improper preservation of SQL mode when renaming databases in cPanel allows execution of SQL in root context.

That is the whole bug. A cPanel account holder renames one of their own databases through the normal interface. The rename path drops the SQL mode that was constraining them, and the statements run as the database superuser instead of as the account's restricted user. From there the account can read, alter or drop any database on the server, extract stored credentials, and plant database-level objects that persist. cPanel's own advisory title calls it Database Privilege Escalation.

The companion, CVE-2026-58047, is quieter: HTTP request smuggling, CWE-444, rated 5.6 medium, described as allowing a "potential leak of credentials." It ships in the same builds, so patching handles both.

The Number That Should Change Your Triage

Most coverage will file this under "critical cPanel bug, patch it." That is correct and it misses the interesting part.

Compare it against April's authentication bypass, the one that was exploited as a zero-day for months before the patch landed:

The bug that requires a login scores higher than the bug that requires nothing. On the same scoring system, by the same CNA.

The entire difference is in the last three metrics. CVSS 4.0 splits impact into the vulnerable system and any subsequent system, and that split is the whole story here. April's bypass was scored as staying inside the panel: total compromise of what it touched, no rated spillover. This one is scored SC:H / SI:H / SA:H, which is the CNA stating plainly that the blast radius leaves the account and takes the host with it.

If your triage rule is "authenticated bugs wait for the next window," this is the case that rule was designed to miss.

What "Authenticated" Means When You Sell Hosting

The prerequisite is a valid cPanel account with access to the MySQL or MariaDB feature. On a dedicated box you administer for one application, that is a genuine barrier and you can breathe.

On a shared server it is a price list.

Anyone who can complete a signup form has the prerequisite. The MySQL feature is on by default for standard packages, because a hosting account without a database is not much of a hosting account. So the attacker profile is not a sophisticated adversary who first has to breach something: it is a customer, or anyone who buys a month of the cheapest plan you sell, or the operator of one site on your server that got compromised through its own outdated plugin.

That last route is the one worth sitting with. Every WordPress install on a shared server is a potential source of valid cPanel credentials. A plugin vulnerability that used to mean "one customer's site is defaced" now has a documented path to "every customer's database on that server." The isolation between tenants was the thing standing between those two outcomes, and this bug is specifically a hole in that isolation.

The same reasoning applies to reseller environments and to any WHM box where you do not personally know every account holder.

Which Builds Are Fixed

cPanel patches across all supported release tiers at once. The CVE record lists the first fixed build per tier, and everything below each one is affected:

The 11.137 development line is represented in the CVE record by cPanel's 9999 sentinel rather than a real build number. The 138 change log records a Targeted Security Release as build 137.9999.98 on July 29, 2026, two days before the CVEs went public. If you run that line, take the update rather than trying to reason about the sentinel.

Check where you actually are:

cat /usr/local/cpanel/version

And confirm which tier that box is even following, because the answer is often not what the team assumes:

grep -i '^CPANEL=' /etc/cpupdate.conf

Automatic Updates Answer A Different Question

cPanel runs upcp nightly by default, and on most servers this was patched before anyone read about it. That is genuinely good, and it is also the reason this section exists rather than a patch-now paragraph.

"Updates are automatic" is a statement about configuration. "This server is on a fixed build" is a statement about state. They diverge, quietly, in the places you would expect: a box where someone set UPDATES=never during a migration two years ago and never set it back, a server pinned to an LTS tier for an application compatibility reason, a machine where the nightly run has been failing on a full /usr partition and nobody reads that mail, or one that has been rebooted into a state where the update never completes.

None of those announce themselves. All of them look fine until you run the version check.

So the useful action is not "enable automatic updates." It is to go read the build number off every cPanel box you are responsible for, today, and compare it against the table above. If you have more than a handful, that is a loop over your inventory, not a login to each panel.

If a server is behind, force it rather than waiting for midnight:

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

On Exploitation

CISA's enrichment of this CVE recorded no known exploitation at the time of writing. That is a snapshot and not a forecast, and the recent history here argues against comfort: April's cPanel bypass was under active exploitation since February, roughly two months before the patch existed, and the Shadowserver Foundation counted tens of thousands of likely-compromised addresses once it was understood.

The difference this time is that the patch came first. That is the window you are in, and it is the only kind of window worth using well.

Worth noting separately: patching closes the hole, it does not undo prior use of it. If a server was behind on the July 29 to 31 window and you have any reason to think an account was hostile, the database layer is where you look. Objects that survive a cPanel update, such as triggers, routines and events owned by other accounts, are the persistence mechanism this particular bug hands out.

What We Would Actually Do

Patch level is the first thing, and for most teams it is the only thing. But two changes are worth making regardless of this specific CVE, because they are what turn a tenant-isolation bug from an incident into a bad afternoon.

First, know your account inventory the way you know your server inventory. A shared server's real attack surface is the list of people who hold accounts on it, and most operators can produce the second list instantly and the first one not at all.

Second, treat "requires authentication" as a severity modifier rather than a severity cap, specifically on multi-tenant systems. This CVE is the argument in one number: 9.4 with a login requirement, against 9.3 without one.

We run and patch cPanel and WHM servers as a managed service, and handle this class of triage as part of security and compliance work. If you are not certain what build your servers are on right now, that uncertainty is the finding. Get in touch.

Sources: CVE-2026-58048 record, CVE-2026-58047 record, cPanel advisory for CVE-2026-58048, cPanel 138 change log, The Hacker News report