A tenant in a shared apartment building found the master key taped behind the mailbox
CVE-2026-58048 is a SQL injection in cPanel & WHM's database rename functionality. When a cPanel user renames a database, the application fails to preserve the user's sql_mode session state — specifically ANSI_QUOTES — and the rename operation executes under the MySQL root context. By injecting a backtick into the new database name (e.g., ` db; GRANT ALL ON *.* TO 'rce'@'%' IDENTIFIED BY 'pwned!'; -- `), an authenticated cPanel account holder can execute arbitrary SQL with full DBA privileges. All supported cPanel & WHM versions prior to the patched builds (11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32) and WP Squared prior to 138.1.6 are affected. The vulnerable endpoint is /execute/Mysql/rename_database`.
The CVSS 4.0 score circulating in secondary databases is 9.4 Critical, which reflects the *theoretical* worst case (SC:H/SI:H/SA:H for subsequent-system impact). That score is directionally correct — the multi-tenant blast radius is real and devastating — but it overstates the practical severity by treating the authentication prerequisite as negligible friction. On shared hosting, buying a $5 account does get you cPanel credentials, so the barrier is genuinely low. However, CISA classified the exploit chain as non-automatable, no active exploitation has been observed as of October 2026, and EPSS sits at 0.56%, all of which argue against a CRITICAL operational rating. A HIGH assessment at 8.4 better reflects the real-world risk envelope for a defender managing fleet patching.
5 steps from start to impact.
Obtain cPanel credentials
- Valid cPanel username and password for the target server
- Network reachability to cPanel port 2083 (HTTPS)
- Enterprise deployments often restrict cPanel access to management VLANs or VPN-only
- MFA-enabled cPanel accounts raise the bar significantly
- Infostealers/phishing add a separate campaign phase before this vuln is reachable
/usr/local/cpanel/logs/login_log; brute-force detectable by cPHulk or external WAF rate-limitingNavigate to database rename function
- MySQL/MariaDB feature enabled for the cPanel account (default: enabled)
- At least one existing database owned by the account
- Hosting providers who have disabled the MySQL feature for reseller sub-accounts block this path entirely
- Some hardened cPanel configs use Feature Manager to restrict database operations
/execute/Mysql/rename_database API call; unusual rename patterns are detectable via log monitoringInject SQL via crafted database name
sql_mode (specifically ANSI_QUOTES) before executing the rename operation as MySQL root, the backtick breaks out of the identifier context and the injected SQL runs with root privileges. The PoC demonstrates payloads including GRANT ALL ON *.* TO ..., SELECT LOAD_FILE(...), and CREATE FUNCTION ... SONAME 'lib_mysqludf_sys.so'.- Vulnerable cPanel version (pre-patch)
- MySQL/MariaDB server accessible from cPanel backend
- Input validation or WAF rules on the cPanel reverse proxy could catch backtick injection, though no default rule exists
- ModSecurity with OWASP CRS in front of cPanel would flag the SQL keywords in the parameter
Achieve MySQL root privileges
wp_users tables, e-commerce transaction data, and cPanel's own internal databases. The attacker can also create new MySQL super-users for persistent access.- Successful SQL injection from step 3
- Database-level audit logging (if enabled) will flag cross-schema access
- Some providers run per-tenant MySQL instances (e.g., CloudLinux MySQL Governor) which limit blast radius
GRANT statements detectable via periodic privilege auditsEscalate to OS-level RCE via UDF
lib_mysqludf_sys.so) to execute operating system commands as the mysql user. If the MySQL secure_file_priv variable is empty and the plugin directory is writable, the attacker writes the UDF library via SELECT ... INTO DUMPFILE and then calls sys_exec() to spawn a reverse shell or deploy a webshell. The tc4dy PoC includes this as an automated module.- MySQL
secure_file_privis empty or includes the plugin directory - Plugin directory is writable by the MySQL process
- UDF loading not disabled via
--skip-grant-tablesequivalent
- Modern cPanel installs on CentOS/AlmaLinux with SELinux enforcing block UDF writes to the plugin directory
- CloudLinux CageFS and hardened MySQL configurations restrict
LOAD_FILEandINTO DUMPFILE - Many hosting providers set
secure_file_privto a restricted path or/dev/null
/execute/Mysql/rename_database endpoint entirely without affecting existing databases or their availability. Deploy within the noisgate mitigation SLA of 30 days for HIGH severity. This is the vendor-recommended temporary mitigation.csf (ConfigServer Firewall) or iptables. This eliminates the remote attack vector for external threat actors while preserving admin access. Deploy within 30 days per the noisgate mitigation SLA.GRANT, CREATE USER, LOAD_FILE, and INTO DUMPFILE commands from non-root sessions.secure_file_priv to a restricted directory or /dev/null in my.cnf. This blocks the UDF-to-RCE escalation path (step 5) by preventing MySQL from writing shared libraries to the plugin directory. Verify with getenforce and SHOW VARIABLES LIKE 'secure_file_priv'./usr/local/cpanel/scripts/upcp --force to update to the patched release for your branch. Target builds: 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32, or WP Squared 138.1.6. This is the definitive remediation. Complete within the noisgate remediation SLA of 180 days for HIGH severity.- ModSecurity / WAF on the web application layer — cPanel's API calls go through its own internal proxy, not through the Apache ModSecurity instance protecting hosted sites. Unless you deploy a WAF *in front of cPanel's port 2083*, OWASP CRS rules won't intercept the injection.
- MySQL user privilege restrictions — cPanel creates per-user MySQL accounts with limited grants, but the vulnerability causes the rename operation to execute as root *server-side*. The user's MySQL privilege level is irrelevant because the injection happens in cPanel's backend code, not in the user's direct MySQL session.
- cPHulk brute-force protection — cPHulk protects against credential stuffing on cPanel login but has zero visibility into post-authentication API abuse. A legitimately authenticated user exploiting this vuln generates no cPHulk alerts.
The supporting signals.
| In-the-Wild Exploitation | Not observed. CISA assessed exploitation status as "none" as of 2026-08-04. Not listed on CISA KEV. No GreyNoise or Shadowserver scanning activity reported for this CVE. |
|---|---|
| PoC Availability | Weaponized PoCs public. tc4dy/CVE-2026-58048-PoC-Exploit includes exploit.py (reverse shell, UDF RCE, persistence, mass scanner) and safecheck.py (audit-safe checker). imbas007/POC-CVE-2026-58048 provides a standalone PoC with Docker lab. Both published within weeks of disclosure. |
| EPSS | 0.00561 (0.56%) — below the 50th percentile. Indicates low predicted exploitation probability over the next 30 days, consistent with the authenticated-access prerequisite. |
| KEV Status | Not listed. As of 2026-10-07, CVE-2026-58048 is not on the CISA Known Exploited Vulnerabilities catalog. |
| CVSS 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 = 9.4 (from secondary databases; no official NVD or vendor CVSS 3.1 vector published). The SC:H/SI:H/SA:H reflects cross-tenant impact on shared hosting. |
| Affected Versions | All cPanel & WHM versions in the 11.x release train prior to patched builds. Also affects WP Squared < 138.1.6. Specific vulnerable branches: 11.110.x, 11.118.x, 11.126.x, 11.134.x, 11.136.x. |
| Fixed Versions | cPanel & WHM: 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32. WP Squared: 138.1.6. Auto-update via /usr/local/cpanel/scripts/upcp on most installs. |
| Exposure Surface | Shodan/Censys data shows approximately 1.5 million cPanel/WHM instances internet-exposed on ports 2083/2087. cPanel manages an estimated 70 million domains globally. ~24% market share among commercial hosting panels (Datanyze 2026). |
| Disclosure & Credit | Disclosed 2026-07-31. Credited to security researcher Vincent55 Yang. CISA classified the vulnerability as non-automatable. |
| Automatability | Non-automatable per CISA SSVC assessment. The authenticated-access requirement and per-server targeting prevent worm-like propagation, though the tc4dy PoC includes a multi-threaded mass scanner module that automates exploitation given a credential list. |
Sources.
- The Hacker News — cPanel Critical Flaw Advisory
- SecurityAffairs — CVE-2026-58048 Full Database Admin Access
- CyCognito — Emerging Threat Analysis
- Indusface — CVE-2026-58048 DB Privilege Escalation
- tc4dy/CVE-2026-58048-PoC-Exploit — Weaponized PoC
- imbas007/POC-CVE-2026-58048 — Security Research PoC
- RedSecureTech — cPanel Critical SQL Injection Patched
- Strix.ai — CVE-2026-58048 Fix & Details
Why this verdict
- Authentication barrier is real but thin: The chain requires valid cPanel credentials (PR:L), which prevents unauthenticated mass exploitation and earns the CISA "non-automatable" label. However, on shared hosting — which is cPanel's dominant deployment model — anyone can obtain credentials for $5–15/month. This friction is measurable but does not meaningfully limit a motivated adversary.
- Multi-tenant blast radius triggers the high-value-role floor: cPanel is canonically a multi-tenant hosting management platform. 100% of its installations occupy this role by definition. Achieving MySQL root through this vuln gives the attacker read/write access to every tenant's database on the server — WordPress credentials, e-commerce transactions, PII. This is mass data egress at server scale, analogous to a hypervisor escape. The role floor for this outcome is HIGH.
- Role multiplier: In its canonical deployment (shared hosting server managing 50–500 tenant websites), the chain succeeds fully and the blast radius is *all tenants on the server* → mass data breach, credential theft, supply-chain compromise of hosted websites. This is tenant → server → all-tenants-on-server scale. On dedicated/enterprise VPS deployments where cPanel manages a single tenant, blast radius shrinks to single-host. Given that shared hosting is >80% of cPanel's installed base, the high-value outcome dominates.
- Weaponized PoCs available, no exploitation observed yet: Two public GitHub repositories provide turnkey exploit tooling including reverse shells and mass scanners. Despite this, no in-the-wild exploitation has been reported by CISA, GreyNoise, or Recorded Future as of October 2026. The window between PoC publication and first exploitation is narrowing.
- OS-level escalation is conditional, not guaranteed: The UDF-to-RCE escalation path (step 5) requires
secure_file_privto be empty and the plugin directory to be writable — conditions that SELinux enforcing and CloudLinux CageFS typically prevent. This caps the worst-case at MySQL root rather than OS root for most hardened deployments.
Why not higher?
A CRITICAL assessment would require either unauthenticated access or confirmed active exploitation. This chain demands valid cPanel credentials, CISA has classified it as non-automatable, and no in-the-wild exploitation has been observed over the 10 weeks since disclosure. The OS-level RCE escalation path is blocked by SELinux and CloudLinux on the majority of modern shared hosting deployments, capping realistic impact at database-level compromise rather than full server takeover.
Why not lower?
The multi-tenant blast radius makes MEDIUM inappropriate. A single malicious tenant achieving MySQL root can exfiltrate every database on a server hosting hundreds of websites. Weaponized PoCs are public and include mass-scanning capabilities. The authentication barrier is near-zero on shared hosting (cPanel's dominant deployment model). With 1.5 million instances internet-exposed and the exploitation tooling already packaged, the exploitation window is open and the potential impact is severe.
Crowdsourced verification payload.
Run this script on each cPanel/WHM server as root (or via sudo). It checks the installed cPanel version against known patched builds and reports VULNERABLE, PATCHED, or UNKNOWN. Example: sudo bash check_cve_2026_58048.sh
#!/usr/bin/env bash
# check_cve_2026_58048.sh — CVE-2026-58048 cPanel SQL Injection Checker
# Run as root on the target cPanel/WHM server.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
if [[ $EUID -ne 0 ]]; then
echo "ERROR: Must run as root" >&2
exit 2
fi
VERSION_FILE="/usr/local/cpanel/version"
if [[ ! -f "$VERSION_FILE" ]]; then
echo "UNKNOWN — cPanel not detected on this host (no $VERSION_FILE)"
exit 2
fi
INSTALLED=$(cat "$VERSION_FILE" | tr -d '[:space:]')
echo "Detected cPanel version: $INSTALLED"
# Parse major.minor.patch from installed version
IFS='.' read -r MAJOR MINOR PATCH <<< "$INSTALLED"
# Patched versions per branch:
# 11.110.0.137, 11.118.0.71, 11.126.0.78, 11.134.0.48, 11.136.0.32
# WP Squared: 138.1.6
check_patched() {
local branch_minor="$1"
local branch_sub="$2"
local patch_level="$3"
local fixed_patch="$4"
if [[ "$MINOR" == "$branch_minor" ]] && [[ "$PATCH" == "$branch_sub" ]]; then
# Compare the build number (4th segment)
local build
build=$(echo "$INSTALLED" | awk -F'.' '{print $4}')
if [[ -z "$build" ]]; then
build=0
fi
if [[ "$build" -ge "$fixed_patch" ]]; then
return 0 # patched
else
return 1 # vulnerable
fi
fi
return 2 # not this branch
}
RESULT="UNKNOWN"
# Check each branch
for branch_info in "110:0:137" "118:0:71" "126:0:78" "134:0:48" "136:0:32"; do
IFS=':' read -r bminor bsub bfix <<< "$branch_info"
if [[ "$MINOR" == "$bminor" ]]; then
build=$(echo "$INSTALLED" | awk -F'.' '{print $4}')
[[ -z "$build" ]] && build=0
if [[ "$build" -ge "$bfix" ]]; then
RESULT="PATCHED"
else
RESULT="VULNERABLE"
fi
break
fi
done
# Check if version is newer than all affected branches (138+)
if [[ "$RESULT" == "UNKNOWN" ]] && [[ "$MINOR" -gt 136 ]]; then
# WP Squared / newer — check if >= 138.1.6
build=$(echo "$INSTALLED" | awk -F'.' '{print $4}')
[[ -z "$build" ]] && build=0
if [[ "$MINOR" -gt 138 ]]; then
RESULT="PATCHED"
elif [[ "$MINOR" -eq 138 ]] && [[ "${PATCH:-0}" -ge 1 ]] && [[ "$build" -ge 6 ]]; then
RESULT="PATCHED"
else
RESULT="VULNERABLE"
fi
fi
# Also check if MySQL feature is disabled (mitigated)
MYSQL_DISABLED=false
if command -v whmapi1 &>/dev/null; then
# Check default feature list for MySQL
FEAT=$(whmapi1 getfeaturelist featurelist=default 2>/dev/null | grep -i 'mysql' || true)
if echo "$FEAT" | grep -qi '0'; then
MYSQL_DISABLED=true
fi
fi
echo "========================================"
echo "CVE-2026-58048 Assessment: $RESULT"
if [[ "$MYSQL_DISABLED" == true ]]; then
echo "NOTE: MySQL feature appears disabled in default feature list (mitigated)"
fi
echo "========================================"
case "$RESULT" in
VULNERABLE) exit 1 ;;
PATCHED) exit 0 ;;
*) exit 2 ;;
esac