On September 8, 2026, cPanel published a security advisory for CVE-2026-67401: a SQL injection vulnerability in the EmailTrack functionality, rated CVSS 9.9 (critical). An authenticated account with ordinary mail permissions — the kind held by any regular hosting customer — can exploit it to write arbitrary files on the server and ultimately execute code as root. No public proof-of-concept exploit exists as of this writing, and there are no confirmed reports of in-the-wild exploitation. Given the low bar for exploitation (a standard customer account, not an internet-wide unauthenticated attack) and cPanel's history in 2026, that is unlikely to remain true for long.
- What: A SQL injection vulnerability in cPanel's EmailTrack functionality, tracked as CVE-2026-67401, disclosed in cPanel's official security advisory on September 8, 2026.
- Severity: CVSS 9.9 (critical).
- Who can exploit it: An authenticated cPanel account with mail permissions — the access level a normal hosting customer already has. This is not an unauthenticated, internet-wide bug; it requires a standard account, including one that has already been compromised through credential reuse or phishing.
- What it leads to: The SQL injection can be used to create an arbitrary file on the server, which chains into code execution as root — a full server takeover, according to cPanel's advisory. cPanel has not published the technical detail of how the injection reaches file-write and then root execution.
- Affected versions: 11.110 before 11.110.0.143, 11.134 before 11.134.0.55, 11.136 before 11.136.0.39, 11.138 before 11.138.0.4, and WP Squared before 11.138.1.9.
- Fixed in: 11.110.0.143, 11.134.0.55, 11.136.0.39, 11.138.0.4, and WP Squared 11.138.1.9.
- Exploitation status as of September 9, 2026: No confirmed public proof-of-concept exploit, no confirmed in-the-wild exploitation, not listed in the CISA Known Exploited Vulnerabilities catalog. A tool circulating under the "PoC" label is a defensive indicator-of-compromise scanner, not a working exploit — its own author describes it that way.
- Discovered by: Security researchers Ali Mustafa (rz1027) and abed1526.
What is CVE-2026-67401?
CVE-2026-67401 is a SQL injection vulnerability in EmailTrack, a cPanel feature that logs and reports on outbound mail activity for an account. According to cPanel's official advisory, an attacker who already holds an authenticated cPanel account with mail permissions can inject malicious SQL through the EmailTrack functionality, and from there create an arbitrary file on the server. That file-write capability is then used to achieve code execution as root, resulting in complete control of the server.
The critical detail is the starting point: this is not a bug that requires an unauthenticated attacker reaching the server from the open internet. It requires an account that already has mail permissions on the box — which describes essentially every paying hosting customer with an active mailbox. On a shared or reseller server, that means a single low-value customer account, or a single account taken over through a reused password or a phishing email, is a sufficient starting point for a full server compromise.
cPanel's advisory does not disclose the specific mechanism connecting the SQL injection to the file-write step, or the file-write step to root code execution. That is a deliberate and standard practice for a freshly patched, high-severity vulnerability: publishing exploit-grade detail before administrators have had time to patch would hand attackers a blueprint. We are not speculating about that mechanism here, and any article claiming to explain the exact technical chain in detail should be treated with skepticism until cPanel itself publishes more.
Am I affected?
You are affected if you run any cPanel & WHM release below the patched build listed for your release line. Every actively maintained release line had at least one affected build; there is no release line that was skipped.
| Release line | Affected (below) | Fixed in |
|---|---|---|
| 11.110 | 11.110.0.143 | 11.110.0.143 |
| 11.134 | 11.134.0.55 | 11.134.0.55 |
| 11.136 | 11.136.0.39 | 11.136.0.39 |
| 11.138 | 11.138.0.4 | 11.138.0.4 |
| WP Squared | 11.138.1.9 | 11.138.1.9 |
How do I check my cPanel version?
Run the following as root over SSH on the server:
/usr/local/cpanel/cpanel -VCompare the output against the "Affected" column above for your release line. If your build number is lower than the fixed build for your line, you are running a vulnerable version and should patch immediately. If you manage cPanel through WHM only, the version is also visible on the WHM home screen under Server Information.
Has it been exploited in the wild?
As of September 9, 2026 — the day after disclosure — there is no confirmed proof-of-concept exploit publicly available, no verified report of active exploitation, and the vulnerability does not appear in the CISA Known Exploited Vulnerabilities catalog. A repository circulating online under a "PoC" label for this CVE is, according to its own author, a defensive scanner that checks logs for indicators of compromise — it does not contain a working exploit.
That is a meaningfully different starting position than a bug that is already being exploited at scale, and it is worth stating plainly rather than inflating for effect. It is not, however, a reason to treat this as low priority. Given a CVSS score of 9.9, a low bar to exploit (an ordinary authenticated mail account rather than a zero-click remote attack), and a full server-takeover outcome, a working exploit chain is a realistic near-term possibility once researchers or attackers reverse-engineer the patch — a well-understood pattern sometimes called "patch diffing." The absence of a public exploit today is a reason to patch now, while you still have the advantage of time, not a reason to wait.
What should I do right now?
1. Patch immediately
If you administer the server, upgrade to the fixed build for your release line listed in the table above. The standard path is through WHM's Software > Update Preferences and Upgrade to Latest Version screens. To force an immediate update from the command line as root:
/usr/local/cpanel/scripts/upcp --forceThis pulls and applies the latest available build for your configured update tier. If your server is pinned to a specific update tier (release, stable, current, or edge) that has not yet received the patched build for your line, check cPanel's official update tier documentation and advisory for guidance before switching tiers on a production server.
2. Verify the patch actually applied
After the update completes, re-run the version check and confirm the build number now matches or exceeds the fixed build for your release line:
/usr/local/cpanel/cpanel -VDo not assume an update job that "completed without errors" actually landed the security fix — confirm the version number directly. This is a habit worth having for every advisory, not just this one.
3. Look for signs of prior compromise
Patching closes the door going forward; it does not undo anything that may already have happened on a server that was vulnerable before today. If your server was running an affected build, it is worth a focused look at the following, particularly on servers with many mail-enabled customer accounts or a history of credential-reuse incidents:
- Exim and cPanel service logs for unusual activity tied to EmailTrack, and for errors or anomalies around the time EmailTrack was accessed by unfamiliar or low-trust accounts.
- Cron tables (
crontab -lfor every account, and/var/spool/cron/) for entries you cannot account for, especially ones that run as root or were added recently. - The authorized SSH keys for root and for every account (
~/.ssh/authorized_keys) for entries nobody on your team recognizes. - Recently created or modified files in
/tmpand other world-writable directories, especially executables or scripts with no clear provenance. - Unexpected new cPanel or WHM accounts, or privilege changes on existing accounts, that nobody on your team created.
If you find anything that does not have a clean explanation, treat the server as potentially compromised and follow your incident response process rather than assuming a single fix resolves it — a root compromise can leave persistence mechanisms far removed from the original entry point.
4. If you cannot patch immediately
Some environments cannot apply an update the moment it ships — change windows, custom configurations, or contractual maintenance policies get in the way. If that is your situation, these steps reduce exposure without eliminating the underlying bug:
- Restrict WHM access to a trusted IP allow-list or a VPN, so the administrative interface is not reachable from the open internet while you plan the update.
- Review which customer accounts actually need mail permissions, and remove them from accounts that do not use email — this shrinks the pool of accounts that could be used as a starting point.
- Increase monitoring on mail-related logs and cron activity for the affected period, so you have a better chance of catching exploitation attempts before the patch lands.
- Schedule the patch as an emergency change, not a routine one. A CVSS 9.9 bug reachable by an ordinary customer account is not a "next maintenance window" issue.
None of these substitute for the patch. They buy time; they do not close the vulnerability.
Part of a pattern: cPanel's difficult 2026
CVE-2026-67401 does not stand alone. It is the third severe cPanel vulnerability of 2026 that follows a similar shape — a relatively ordinary level of access turning into full root control:
- CVE-2026-41940 (disclosed April 2026, CVSS 9.8): an authentication-bypass vulnerability that was exploited in the wild and linked to a ransomware campaign before a patch was broadly applied. We covered the technical pattern and the ransomware connection in our earlier analysis of CVE-2026-41940.
- CVE-2026-65643 (disclosed August 2026): a vulnerability that allowed an account with domain-level (not server-level) privileges to reach root.
- CVE-2026-67401 (disclosed September 8, 2026): the SQL injection covered in this article, reachable from an ordinary mail-enabled account.
The common thread across all three is not a single coding mistake repeated three times — it is a recurring outcome. In each case, an account with meaningfully less trust than a server administrator found a path to root. That pattern is worth paying attention to independent of any single CVE, because it says something about how much distance exists, architecturally, between an ordinary customer account and full server control on a given platform. We looked at CVE-2026-41940 specifically through that lens in what it reveals about a decades-old codebase, and at the general question of blast radius in privilege escalation in hosting panels.
Where Panelica fits
It would be dishonest to frame this as "Panelica does not have this bug, so switch." That statement would be true today and says nothing about tomorrow. No control panel of meaningful size and age — commercial or open-source, Panelica included — can credibly promise it will never ship a vulnerability. Software has bugs. The honest question is not whether a bug can exist; it is what happens when one does.
What CVE-2026-67401 illustrates is a specific failure mode: an account with ordinary, non-administrative permissions reaching root. That is exactly the scenario Panelica's isolation architecture is built to contain. Every account on Panelica runs inside five independent layers by default, on every plan, not as an optional or paid add-on:
| Isolation layer | What it limits |
|---|---|
| Cgroups v2 resource slices | A single account's CPU, memory, and I/O usage, bounded per user |
| Linux PID and mount namespaces | What files and processes an account can see, independent of application-level permission checks |
| SSH chroot jails | Shell and SFTP sessions confined to that account's own directory tree |
Per-user, per-version PHP-FPM pools with open_basedir and disable_functions | What application code running under an account can read or execute outside its own scope |
| Dedicated Unix UID/GID per account | File ownership and permission boundaries enforced by the operating system itself |
None of that isolation prevents a bug from being found in a specific feature's code. What it is designed to do is bound the consequence: if a flaw is ever found in a single feature on a single account's request path, the goal of the architecture is to keep that account's blast radius limited to its own resources rather than opening a path to root and, from there, to every other tenant on the server. That is a different claim than "we are unhackable," and it is the only honest claim a panel vendor can make.
If you are evaluating hosting panels after a disclosure like this one, our feature-by-feature comparison with cPanel and the full architecture on our features page are a reasonable place to look at what isolation and security controls ship by default, rather than as add-ons layered on afterward.
Frequently asked questions
What is CVE-2026-67401?
A SQL injection vulnerability in cPanel's EmailTrack functionality, disclosed by cPanel on September 8, 2026, with a CVSS score of 9.9. An authenticated account with mail permissions can use it to write an arbitrary file on the server, which leads to code execution as root.
Do I need to be an unauthenticated attacker to exploit this?
No. The vulnerability requires an authenticated cPanel account with mail permissions — the access level of an ordinary hosting customer. It is not an unauthenticated, internet-facing exploit, which is precisely what makes it dangerous on multi-tenant servers: a single low-trust customer account, or one compromised through credential reuse or phishing, is a sufficient starting point.
Which cPanel versions are affected?
11.110 before build 11.110.0.143, 11.134 before 11.134.0.55, 11.136 before 11.136.0.39, 11.138 before 11.138.0.4, and WP Squared before 11.138.1.9. All five affected lines have a patched build available as of the September 8, 2026 advisory.
How do I check whether my server is patched?
Run /usr/local/cpanel/cpanel -V as root over SSH and compare the build number against the fixed builds listed above. If you are below the fixed build for your release line, update immediately with /usr/local/cpanel/scripts/upcp --force or through WHM's update screens, then re-check the version to confirm it landed.
Has CVE-2026-67401 been exploited in the wild?
Not as of September 9, 2026. There is no confirmed public proof-of-concept exploit, no verified in-the-wild exploitation, and it is not on the CISA Known Exploited Vulnerabilities catalog. A tool labeled "PoC" in some online listings is a defensive log scanner for indicators of compromise, not a working exploit, according to its own author. Given the severity and the low bar to exploit, this status can change quickly, and patching should not wait for it to.
Is Panelica affected by CVE-2026-67401?
No — this is a cPanel-specific vulnerability in cPanel's EmailTrack code, and it does not exist in Panelica. That said, no panel of meaningful size can credibly claim to be permanently immune to every future vulnerability. What Panelica's five-layer isolation architecture is designed to do is limit how far a compromised low-privilege account can reach if a comparable flaw is ever found in any single feature, rather than eliminate the possibility of bugs entirely.
The takeaway
CVE-2026-67401 is a critical, patched vulnerability that turns an ordinary mail-enabled cPanel account into a path to root. There is no public exploit today, but the combination of a 9.9 CVSS score, a low bar to reach the vulnerable code, and a full server-takeover outcome means the sensible response is to patch now, verify the patch, and check your logs — not to wait and see whether exploitation shows up first. Set aside this specific CVE, and the broader pattern across CVE-2026-41940, CVE-2026-65643, and now CVE-2026-67401 is worth remembering the next time you evaluate the isolation architecture underneath whatever panel you run: on a shared server, the distance between one ordinary customer account and root is not a detail. It is the whole security model.