Critical cPanel Vulnerability (CVE-2026-67401): How an EmailTrack SQL Injection Grants Root Access

On September 8, 2026, cPanel published a security advisory disclosing a critical vulnerability that lets a standard, authenticated hosting account fully compromise the underlying server. Tracked as CVE-2026-67401, the flaw sits in cPanel’s EmailTrack functionality, where a SQL injection can be chained into arbitrary file creation and, ultimately, code execution as root.

Most vulnerabilities in this space expose customer data. This one breaks the boundary that shared hosting depends on: tenant isolation. An attacker with basic mail-related privileges can escalate to root, gaining administrative control over Web Host Manager (WHM) and every other account on the machine.

This piece covers the technical mechanics of CVE-2026-67401, the likely attack chain, where it fits among cPanel’s other 2026 disclosures, and steps for checking whether a server has already been hit.

Executive summary

For sysadmins and MSPs who need the operational details fast:

• CVE identifier: CVE-2026-67401
• Vulnerability type: SQL injection leading to arbitrary file write and root privilege escalation
• Affected component: cPanel & WHM EmailTrack module
• Prerequisites: an authenticated cPanel account with mail-related privileges
• Impact: full server takeover (root RCE)
• Credit: discovered and responsibly disclosed by security researchers Ali Mustafa (rz1027) and abed1526

Fixed builds

cPanel has released patches across all supported release lines. Make sure your servers are running at least these build numbers:

From SQL injection to root: the technical path

cPanel’s advisory names SQL injection as the root cause but doesn’t explain how a database injection turns into filesystem access and root code execution. Understanding that gap matters for defending against it.

cPanel’s backend runs mostly on Perl and leans on MySQL or MariaDB for state, logging, and configuration storage. The EmailTrack module logs email delivery stats, opens, clicks, and bounces to the database.

Arbitrary file write via MySQL’s FILE privilege

The most plausible explanation involves MySQL’s file privileges. When a tracking event fires, EmailTrack writes data to the database. If the module doesn’t sanitize user-controlled input, such as custom email headers, tracking parameters, or envelope senders, before building the query, an attacker can inject SQL syntax.

If the database user running these queries has the FILE privilege, the attacker can use SELECT ... INTO OUTFILE or SELECT ... INTO DUMPFILE to write query output straight to the filesystem. Target a directory that root-level cron jobs watch, such as /etc/cron.d/, /etc/cron.hourly/, or /var/spool/cron/root, or one of cPanel’s internal hook directories, and the payload runs as root the next time cron cycles.

Unsafe deserialization or eval as an alternative path

cPanel daemons like cpsrvd (the cPanel web server) and cpdavd regularly poll the database for queued tasks and tracking logs. If the injected SQL plants malicious serialized Perl objects or raw code in a record, and a root-level daemon then deserializes or evals it without checking, the attacker gets code execution as root directly. This mirrors the August 27, 2026 domain parking flaw, which cPanel classified as an eval injection leading to root access.

cPanel keeps exact exploit paths under embargo to slow mass weaponization, so administrators should treat both paths as live and audit accordingly.

The attack chain

Here’s the likely progression, and why a standard WAF may not catch the first step:

1. Access. The attacker needs a valid, authenticated cPanel account with mail-related privileges: a legitimate customer, a compromised WordPress site with a cPanel plugin, or a cheap account bought from a shared host.
2. Payload crafting. They build a malicious email or manipulate a tracking request with a SQL injection payload aimed at INTO OUTFILE or at backend Perl objects.
3. Database manipulation. EmailTrack processes the request and writes the payload into the database, or onto the filesystem via the database engine.
4. Privilege escalation. The payload lands in a sensitive location, like a root cron job. When the system runs that job, or a root-level cPanel daemon processes the tainted record, the attacker’s code runs as root.
5. Lateral movement. With root access, the attacker can read every account on the box, steal credentials, install persistent malware, alter databases, and pivot into the provider’s internal network.

Why shared hosts are exposed

Shared hosting’s security model depends on the wall between the cPanel user (customer) and the WHM root user (provider). CVE-2026-67401 removes that wall.

Compromising one cPanel account is a different problem from compromising WHM. As the security firm Hadrian noted during the April 2026 cPanel incident, WHM access hands an attacker root control over the entire server. Once an attacker has root, tenant isolation is gone, and the provider and every other customer on that box are exposed.

Larger providers have moved fast. Liquid Web, for one, has already started applying patches across its hosting fleet and pushing manual cPanel updates. Smaller boutique hosts and sysadmins running unmanaged VPS setups are more exposed if they’re relying on delayed, automated update cron jobs.

Patching cPanel and WHM

Patched builds are available for the 110, 134, 136, and 138 release lines. Older lines like 11.118 and 11.126, patched back in July, no longer appear in current advisories, which suggests they’ve hit end of life and won’t get further security updates.

WHM interface

1. Log in to WHM as root.
2. Go to Home > cPanel > Upgrade to Latest Version.
3. Click Upgrade to pull the latest patched build.

Command line

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

On workarounds: Unlike the July 30 database flaw, where cPanel suggested pulling the MySQL feature from users who couldn’t upgrade right away, there’s no interim mitigation listed for this one. Since exploitation requires mail privileges, disabling EmailTrack or restricting mail access at the package level in WHM may shrink the attack surface, but patching is the only real fix.

Checking for prior compromise

cPanel’s September 8 advisory doesn’t say whether installing the patch removes a root backdoor planted before the fix went out. That’s a real gap, and it means admins need to check their own systems rather than assume the patch cleans up after itself.

1. Check cron jobs

Attackers often use cron for persistence. Look for unauthorized scripts created around or before September 8.

# Check for recently modified cron files
ls -la /etc/cron.*
ls -la /var/spool/cron/
cat /var/spool/cron/root

2. Look for arbitrary file writes

Search for files written by the database user, or files in web-accessible directories containing shellcode or reverse shell payloads.

# Find files modified in the last 14 days in critical cPanel directories
find /usr/local/cpanel/ -type f -mtime -14 -ls
find /var/spool/ -type f -mtime -14 -ls

3. Check database logs

If MySQL/MariaDB general or slow query logging is on, search for INTO OUTFILE or DUMPFILE queries from cPanel’s internal database users.

grep -i "into outfile" /var/lib/mysql/*.log
grep -i "INTO DUMPFILE" /var/lib/mysql/*.log

4. Review cPanel API and access logs

Check /usr/local/cpanel/logs/ for unexpected API2 or UAPI calls tied to EmailTrack, especially from unfamiliar IPs or outside normal business hours.

Where this fits in cPanel’s 2026 track record

CVE-2026-67401 is the latest in a run of high-severity cPanel disclosures this year:

• April 2026 (CVE-2026-41940): A pre-authentication bypass via CRLF injection, actively exploited in the wild and used in ransomware campaigns before patches saw wide deployment.
• July 30, 2026: A database flaw let accounts with database access run SQL commands with full administrative privileges, effectively granting database root.
• August 27, 2026: An eval injection in the domain parking feature let authenticated users reach the same end point as CVE-2026-67401: root code execution.

The pattern points toward attackers focusing on post-authentication paths. A compromised WordPress site or a cheap shared hosting account is enough of a foothold to go after the cPanel layer underneath.

No public exploit code or proof-of-concept for CVE-2026-67401 had surfaced in public repositories or on CISA’s Known Exploited Vulnerabilities catalog as of September 9, 2026. That’s not much comfort: exploits for the July and August flaws showed up in underground repos shortly after disclosure, and the April auth bypass was weaponized before a patch even landed.

Recommendations

1. Patch now. Don’t wait for a maintenance window. Run /usr/local/cpanel/scripts/upcp --force across all supported nodes.
2. Assume breach on unpatched nodes. If a server was running a vulnerable 110, 134, 136, or 138 build in the last 72 hours, treat the root filesystem as untrusted. Patching doesn’t remove rootkits or persistent cron jobs already in place.
3. Monitor tenant activity. Host-based intrusion detection tools like OSSEC or Wazuh can flag unauthorized changes to /etc/cron.d/, /usr/local/cpanel/, and /var/spool/ from non-root users or unexpected database processes.
4. Check for legacy versions. Anything older than the 11.110 line, such as 11.118 or 11.126, is unsupported and won’t get patches for this or future issues. Move to a supported LTS or release tier.

cPanel is continuing to work with researchers Ali Mustafa and abed1526 to close these gaps, but for now, patching quickly and checking for prior compromise is on the administrator.