Short answer: CVE-2026-58048 is a SQL injection in cPanel and WHM that turns an ordinary hosting customer into the database superuser. Renaming a database does not preserve SQL mode correctly, so a backtick placed in the new name escapes the identifier and the rest of the customer's input executes as MySQL root. It scores 9.4, it needs nothing more than a valid cPanel account with the MySQL feature, and proof-of-concept exploit code is now public on GitHub. If you run cPanel, confirm your build is one of the patched ones today. If you run anything else, the interesting part is why this happened, because the same mistake is available to every panel that builds SQL from a customer-supplied name.
What the Bug Is
The vulnerable operation is the UAPI call that renames a database. Renaming is not a single statement in MySQL; it means creating the new database, moving every table across, and dropping the old one. The panel performs that work with administrative privileges, because a customer cannot create databases at the server level on their own.
Two things then go wrong at once.
The first is identifier handling. The new name arrives from the customer and ends up inside a statement where MySQL expects an identifier. A backtick in the name closes the identifier early, and whatever follows is parsed as SQL rather than as part of a name.
The second is SQL mode. The customer's session runs with ANSI_QUOTES, and that mode is improperly preserved when the rename executes in root context. SQL mode changes how MySQL interprets quoting: with ANSI_QUOTES set, a double-quoted string is read as an identifier rather than as a string literal. Escaping logic that is correct under one mode becomes incorrect under the other. This is why the advisory describes the root cause as improper preservation of SQL mode rather than simply as missing escaping: the escaping was there, and the mode made it wrong.
The result is arbitrary SQL executed as the database root user. From there an attacker can read or alter any database on the server, extract credentials that applications store in their own tables, and create database-level objects that survive the obvious cleanup. Depending on the engine configuration and the operating system, that position can be extended further.
If You Run cPanel
The flaw was published on 31 July 2026 and fixed builds exist on every maintained branch. The versions listed as affected are 11.110.0.137 and below, 11.118.0.71 and below, 11.126.0.78 and below, 11.134.0.48 and below, 11.136.0.32 and below, and 11.137.9999.99 and below, along with WP Squared below 11.138.1.6. Check what you are actually running:
/usr/local/cpanel/cpanel -VCompare that against the patched build for your branch and update if you are at or below an affected version. Because exploit code is public, the window between "we will schedule it" and "somebody tried it" is no longer theoretical.
After updating, it is worth looking for what an exploitation attempt would have left behind. Database-level persistence does not show up in a file scan:
- Unexpected accounts and grants. Review
mysql.userand the grants on it for accounts that do not correspond to a hosting account, and for customer accounts that hold privileges beyond their own databases. - Routines and triggers with a privileged definer. A stored procedure, function or trigger created with
DEFINER=rootruns with root's privileges whenever it fires. Inventory these and confirm each one belongs to something you installed. - Events. The MySQL event scheduler can re-create an attacker's access on a timer long after the entry point is patched.
- Binary logs. If binary logging is on, the statements executed during the relevant period are recorded. That is the most direct evidence available of whether the path was used.
Does This Affect a Panelica Server?
No, and the two reasons are worth being specific about, because "we are not cPanel" is not an answer.
There is no database rename feature. Panelica does not expose database renaming to customers or to administrators, so the vulnerable operation has no counterpart in the panel. Renaming a database is a destructive, multi-step operation that real hosting workflows rarely need; the panel's answer to "I picked the wrong name" is to create the database you want and move the data with the tools designed for it. That decision was made for operational reasons rather than security ones, but it removes the entire code path this CVE lives in.
Customer-supplied names never reach SQL as text. Before any statement is built, a database or database-user name must match a strict allowlist: letters, digits and underscore, between one and thirty-two characters. A backtick, a quote, a space or a semicolon fails validation and the request is refused with an error. The name is then prefixed with the account's own domain, so names are additionally scoped per account rather than chosen freely across the server. For PostgreSQL databases the panel goes through the driver's identifier quoting function rather than string concatenation, and the role it creates is explicitly restricted at creation time: no superuser, no database creation, no role creation, no replication.
Two smaller behaviours in the same area are worth mentioning because they address the adjacent failure mode, silent adoption. When a requested database or database user already exists on the server, Panelica refuses the request and tells you, rather than quietly taking ownership of whatever is already there. That matters on servers that were migrated from another panel, where orphaned databases are common.
If you are evaluating panels after this advisory, those are the kinds of questions that separate them: is the dangerous operation present at all, is customer input validated before it becomes SQL, and does the privileged process assume the customer's session settings. See how Panelica handles databases for hosting accounts.
The Engineering Lesson, for Anyone Building a Panel
This vulnerability is a clean illustration of a problem that is easy to describe and easy to get wrong.
- Identifiers are not strings. Prepared statements protect values, not table and database names. An identifier that comes from user input must either go through the driver's identifier-quoting function or pass an allowlist. Hand-rolled escaping for identifiers is a recurring source of exactly this class of bug.
- Never inherit a caller's SQL mode in a privileged operation. If code runs with elevated privileges, it should set the SQL mode it expects rather than accept whatever the session arrived with. Quoting behaviour that depends on a mode the attacker controls is not quoting.
- Allowlist, do not sanitise. Removing dangerous characters from a name invites arguments about which characters are dangerous. Accepting only a known-safe character set ends the argument, and for database names the practical cost is zero: nobody needs a backtick in a database name.
- Ask whether the feature needs to exist. The safest implementation of a rarely used destructive operation is often the one that was never written. Every privileged code path a panel exposes is a path somebody has to keep correct forever.
Frequently Asked Questions
What is CVE-2026-58048?
It is a critical SQL injection and privilege escalation vulnerability in cPanel and WHM, scored 9.4 on CVSS v4.0. SQL mode is not properly preserved when a database is renamed in root context, so a backtick in the new database name escapes the identifier and the attacker's SQL executes as the MySQL root user. It is classified as CWE-89.
What does an attacker need in order to exploit it?
A valid cPanel account with the MySQL or MariaDB feature enabled. No administrator access and no special configuration are required, which is why it scores higher than some unauthenticated flaws: the privilege gain from ordinary customer to database superuser is complete.
Which cPanel versions are affected?
Versions 11.110.0.137 and below, 11.118.0.71 and below, 11.126.0.78 and below, 11.134.0.48 and below, 11.136.0.32 and below, and 11.137.9999.99 and below, plus WP Squared below 11.138.1.6. Check your build with /usr/local/cpanel/cpanel -V and update to the patched build on your branch.
Is there public exploit code for CVE-2026-58048?
Yes. Proof-of-concept exploit code has been published, which lowers the skill required to attempt it and shortens the time you have to patch. Treat any unpatched build as exposed rather than as theoretically affected.
How would I know whether the vulnerability was used on my server?
Look for database-level persistence rather than files: unexpected MySQL accounts or grants, stored procedures, functions and triggers whose definer is root, and scheduled events. If binary logging was enabled, the statements executed during the period are recorded and are the most direct evidence available.
Is Panelica affected by CVE-2026-58048?
No. Panelica exposes no database rename operation, so the vulnerable code path has no equivalent. Database and database-user names must match an allowlist of letters, digits and underscore before any SQL statement is constructed, PostgreSQL identifiers are quoted through the driver's identifier-quoting function, and created roles are restricted at creation time with no superuser, database creation, role creation or replication rights.
What is the general fix for this class of bug?
Validate identifiers against an allowlist or quote them with the database driver's identifier-quoting function, and have privileged code set its own SQL mode instead of inheriting the caller's. Prepared statements alone do not help, because they parameterise values rather than table and database names.