cPanel has patched CVE-2026-67401, a serious vulnerability in the EmailTrack functionality of cPanel & WHM that allows an authenticated hosting account with mail-related privileges to create arbitrary files on the server and ultimately execute code as the root user. cPanel says every supported version of cPanel & WHM was affected and has released corrected builds across the 11.110, 11.134, 11.136 and 11.138 branches, along with WP Squared. The fixed versions are 11.110.0.143, 11.134.0.55, 11.136.0.39, 11.138.0.4 and WP Squared 11.138.1.9. The vendor describes the underlying issue as an SQL injection vulnerability in EmailTrack and states plainly that successful exploitation provides full control of the server. 

The most important aspect of the vulnerability is not that SQL injection exists in a hosting control panel. The real security problem is the privilege transition. The attacker begins as an ordinary authenticated cPanel customer with mail-related privileges and ends up executing commands as root on the host operating system. That crosses several security boundaries at once: from application user to server filesystem access, from one hosting account to other tenants, and finally from an unprivileged customer context into complete administrative control of the physical or virtual server.

In a shared-hosting environment, those boundaries are fundamental to the entire service model. Hundreds of customers may run websites, databases and mailboxes on one system while reasonably assuming that another customer cannot inspect or modify their data. Root compromise destroys that assumption completely. An attacker who successfully exploits CVE-2026-67401 could potentially read other customers’ application files, retrieve database credentials, modify hosted websites, create new accounts, install persistent malware or steal secrets belonging to every tenant hosted on the same machine. The vulnerable account itself may therefore represent only the initial foothold rather than the actual target.

This is what makes vulnerabilities in hosting control panels disproportionately dangerous compared with flaws in individual websites. Compromising one WordPress installation normally compromises one tenant unless additional server weaknesses exist. Compromising the cPanel privilege boundary can potentially expose the infrastructure underneath many independent applications simultaneously. The attack effectively changes from website compromise into hosting-platform compromise.

The vulnerability also illustrates why authenticated flaws should not automatically be treated as lower risk. Requiring an account sounds reassuring until one considers how easy hosting accounts can be to obtain. An attacker may simply purchase legitimate low-cost hosting, compromise the credentials of an existing customer through phishing or password reuse, or take over a poorly maintained website account. If ordinary customer access satisfies the exploitation prerequisite, authentication provides only a modest barrier.

The requirement for mail-related privileges deserves similar interpretation. Email functionality is not an unusual administrative permission on a cPanel platform. It is one of the fundamental services hosting customers commonly use. The attacker therefore does not appear to require WHM administrative rights or a specially privileged reseller account before beginning the attack. cPanel’s advisory specifically states that an authenticated account holder with mail-related privileges is sufficient.

Technically, the published advisory leaves an important part of the exploit chain unexplained. cPanel calls the flaw an SQL injection in EmailTrack but does not publicly describe exactly how the injection is transformed into arbitrary file creation and ultimately root code execution. The Hacker News also notes this gap in the current disclosure. That restraint may be intentional to reduce immediate exploit development, but from a defensive perspective the final consequence is already sufficient to determine urgency: an ordinary hosting user can cross into root.

Arbitrary file creation is itself an extremely powerful primitive on a Linux hosting server. If attacker-controlled content can be written into locations processed by privileged scripts, cron jobs, configuration loaders, package mechanisms or root-owned services, the path to command execution can become relatively short. Even without the exact exploit chain, administrators should therefore consider filesystem integrity around privileged directories as part of their investigation.

The vulnerability also arrives at an uncomfortable time for cPanel administrators because it follows several other recent privilege-boundary flaws. On August 27, cPanel disclosed CVE-2026-65643, a vulnerability in domain parking and addon-domain functionality that similarly allowed an authenticated hosting customer to create arbitrary files and achieve root code execution. Earlier in the summer, CVE-2026-58048 allowed an authenticated account with database access to execute SQL with database root privileges, with possible operating-system compromise depending on configuration.

The repetition is strategically important. These vulnerabilities arise in different functionality, but they expose the same architectural danger: functionality available to ordinary hosting customers can unexpectedly cross into highly privileged server operations. When several independent paths appear over a short period, hosting providers should treat the situation as more than a sequence of unrelated patch tickets. It warrants broader review of how cPanel mediates interactions between tenant-controlled input and privileged backend services.

The central secure-design principle should be that tenant-controlled input never directly determines privileged filesystem paths, database commands or execution behavior without strong validation and isolation. Root-owned processes should consume as little customer-controlled data as possible. Where privileged helpers are necessary, they should expose narrowly defined operations rather than accepting flexible parameters that can accidentally become command or path injection primitives.

For hosting providers, patching should be immediate. cPanel’s official guidance is simply to upgrade to the latest corrected build, and unlike some previous disclosures it does not provide an interim workaround for organizations unable to update immediately. That absence means network or feature restrictions may reduce exposure but cannot be considered vendor-supported substitutes for the patch.

Administrators can update through WHM or force an update from the command line using cPanel’s standard update mechanism. More important than initiating the update, however, is verifying the resulting build. In large hosting environments, update channels, maintenance windows or failed package operations can leave individual servers behind even after central automation reports success. Operators should inventory the actual installed cPanel version on every production host and compare it with the appropriate fixed release.

Organizations should also avoid assuming that installing the new build proves the server was never compromised. The Hacker News notes that cPanel has not published guidance explaining how administrators can determine whether exploitation occurred before patching. In the absence of vendor-specific indicators, hosting providers should perform general compromise hunting on systems that were exposed while vulnerable.

That review should include recently created or modified files in privileged locations, unusual root-owned scripts, new cron entries, suspicious systemd services, unfamiliar SSH keys, unexpected accounts and binaries placed in temporary or web-accessible directories. Administrators should also inspect cPanel and web logs for unusual EmailTrack activity originating from hosting accounts that normally make little use of the feature.

Process and network telemetry can provide another layer of evidence. Unexpected shells, scripting interpreters or outbound connections launched from cPanel-associated services deserve investigation, particularly where they occur shortly after EmailTrack requests. Root-level reverse shells or new external C2 traffic may be easier to identify than the original SQL injection itself.

External logging is especially valuable because root compromise means local evidence can no longer be fully trusted. A successful attacker may modify logs or remove files after gaining control. cPanel authentication events, web requests, system logs and network-flow records should therefore be forwarded to independent infrastructure where possible.

Credential exposure should also be considered. A root attacker can potentially read configuration files belonging to hosted applications, including WordPress database passwords, API keys, SMTP credentials, cloud tokens and SSH keys. If compromise is confirmed, incident response should therefore extend beyond the cPanel server itself. Customer credentials stored on that host may need rotation even if individual websites show no obvious modifications.

This produces an awkward but necessary responsibility for hosting providers. One exploited shared server can create a downstream incident across many unrelated customers. Providers need a process for identifying which tenants were hosted on the affected machine during the compromise window and determining what information each tenant may have exposed through local files and databases.

File integrity monitoring is particularly useful in shared-hosting infrastructure because mass modification often reveals post-exploitation activity. Attackers gaining root may inject malicious JavaScript into multiple customer sites, install web shells across accounts or alter common PHP configuration to create persistence. A baseline of customer filesystem state can help distinguish ordinary site updates from cross-tenant modification.

Web-hosting providers should also revisit account isolation mechanisms such as CageFS or equivalent containerization and filesystem controls. These technologies can substantially restrict what one hosting account can see under normal operation. However, they cannot be expected to provide complete protection once an attacker obtains root on the host. Root-level vulnerabilities therefore sit underneath many of the isolation mechanisms customers rely upon.

That is another important architectural distinction. Tenant isolation limits what one ordinary account can do to another account. It is not designed to remain authoritative after the management platform itself has elevated the attacker to root. The correct defense is therefore to prevent tenant-to-root transitions in the first place, while using isolation as additional protection against ordinary account compromise.

The lack of known exploitation should provide some context but not reassurance. As of September 9, The Hacker News found no public exploit code or reports of active exploitation for CVE-2026-67401, and the flaw was not in CISA’s Known Exploited Vulnerabilities Catalog. There was also no published CVSS score in the CVE record at that point. None of those facts changes the technical consequence documented by cPanel: successful exploitation results in root access.

In fact, the timing creates a predictable risk window. The fixed and vulnerable versions are now publicly identifiable. Security researchers and attackers can compare releases to determine which code changed, a process that may reveal the exploit path even if cPanel has deliberately withheld technical details. Hosting providers therefore benefit from patching before reverse engineering turns the vendor’s concise advisory into a complete public exploit.

Recent cPanel history makes that possibility especially relevant. Public repositories claiming exploits for earlier cPanel flaws have already appeared, and the platform has been targeted in real-world attacks through other vulnerabilities. A hosting control panel is an attractive target because one successful exploit can yield access far beyond a single account.

The broader lesson from CVE-2026-67401 is therefore about trust concentration.

Shared hosting is economically efficient because many independent customers rely on one management platform to keep their accounts separate.

But that efficiency also concentrates privilege.

Each customer is intentionally given enough control to manage websites, databases and email.

The platform’s job is to ensure that this control stops exactly at the tenant boundary.

CVE-2026-67401 breaks that boundary.

A customer begins with permission to manage mail.

They end with root control of the server.

And once that happens, “shared hosting” acquires an entirely different meaning.

cPanel has patched a flaw that it says lets a single hosting account take control of an entire server. An authenticated account holder with mail-related privileges can create files of their choosing on the server through EmailTrack and, from there, run code as the root user. cPanel published the advisory on September 8 and says every supported version of cPanel and WHM is affected.

Source: New cPanel Flaw Lets a Hosting Account With Mail Privileges Run Code as Root via The Hacker News — published 09 Sep 2026.