CVE-2026-67401: the cPanel EmailTrack flaw that turns mail access into root

CVE-2026-67401 is the vulnerability behind TSR-2026-09-08, the Targeted Security Release cPanel pre-announced on 7 September and shipped the next day. The CVE record landed on 9 September with a CVSS score of 9.9 — a SQL injection in EmailTrack, the subsystem behind the "Track Delivery" feature that lets a cPanel account holder review logs and delivery reports for their own mail. An account with mail-related privileges can abuse it to write arbitrary files, and from there execute code as root. Every supported branch was affected.

This is the second cPanel & WHM flaw to reach a near-maximum severity score in five months, after CVE-2026-41940 in April. Unlike that one, this bug requires an authenticated account rather than nobody at all — which matters for how you prioritise the fix and where you look for abuse.

What EmailTrack does and why it's dangerous here

EmailTrack stores mail delivery events — sender, recipient, subject, delivery status — so an account holder can look up "did this message actually go out." The values that populate those records feed into a database query without being properly sanitised. An attacker with a mail-privileged cPanel account can craft input that breaks out of the intended query and, chained with cPanel's own file-writing logic, plants a file of their choosing on disk. Because the write happens in a context that runs as root, the attacker turns "I have one hosting account with mail access" into "I own the server."

The privilege bar is lower than it sounds. Mail-related privileges are granted by default to standard cPanel accounts, to email-only accounts on reseller packages, and in some configurations to webmail-only users. Any shared server with self-service signups or a compromised customer account is in scope — this is not limited to accounts you'd call "trusted."

Affected versions and fixed builds

Every currently supported branch needed a patch:

That spread matches the tier layout in cPanel update tiers explained: the fix shipped simultaneously to the LTS branch your frozen boxes sit on, the RELEASE/STABLE branch most production fleets run, and the CURRENT branch that's about to be promoted. There is no version you can hide behind by staying conservative — TSRs bypass tier boundaries by design.

Check your fleet

/usr/local/cpanel/cpanel -V

Compare against the fixed build for your branch above. Anything below it needs the patch now, not on the next maintenance window — this is a working root-privilege path, not a theoretical one.

To sweep a fleet from one place:

for h in $(cat servers.txt); do
  printf '%s ' "$h"
  ssh -n "root@$h" '/usr/local/cpanel/cpanel -V 2>/dev/null || echo unreachable'
done

If a server reports a branch that isn't in the table at all — 11.86, 11.118, 11.126, 11.130, 11.132 — it's already past end of life and will not receive this fix. Move it to a supported branch first:

echo 'CPANEL=lts' > /etc/cpupdate.conf
echo 'updates=daily' >> /etc/cpupdate.conf
/usr/local/cpanel/scripts/upcp --force

Apply the patch

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

Then confirm the version and that the run completed cleanly:

/usr/local/cpanel/cpanel -V
grep -i 'fix\|abort\|error' /var/cpanel/updatelogs/update-$(date +%Y%m%d)*.log | tail

If upcp errors out partway, work through fixing cPanel update failures in upcp rather than re-running it blind — a half-applied update on top of a broken repo state is harder to diagnose than starting clean.

Look for signs of abuse

As of publication there's no confirmed in-the-wild exploitation and no public proof-of-concept, and the CVE isn't in CISA's Known Exploited Vulnerabilities catalog. That can change quickly once technical write-ups circulate, so it's worth a quick look at any server that was unpatched and had self-service or low-trust mail accounts on it:

• Check /usr/local/cpanel/logs/access_log for unusual request patterns against EmailTrack endpoints (/cpsess*/frontend/*/email/emailtrack* and the equivalent API calls) from account sessions rather than admin sessions.
• Look for files owned by root with unexpected modification times in locations a mail-privileged account has no legitimate reason to write to — /etc/, cron directories, or /usr/local/cpanel itself.
• Cross-reference against your account list: does the source account for any suspicious EmailTrack activity match a customer you don't otherwise trust, or an account created shortly before the activity?

If you find a file that shouldn't exist, treat the box as compromised, not just vulnerable. A root-owned dropped file means the escalation already worked — patching now stops new exploitation but doesn't undo whatever that file set up (a cron job, an SSH key, a modified binary). Restore from a JetBackup or R1Soft point that predates the suspicious activity rather than patching in place and hoping.

Why this keeps happening on the mail stack

EmailTrack joins a run of cPanel mail-adjacent bugs this year, and the pattern is consistent: features that read account-supplied data (sender, subject, delivery status) back out of a database without full sanitisation, running in a context with more privilege than the data source warrants. If you're auditing your own exposure rather than just patching, the question worth asking isn't "did I patch this CVE" — it's "which other cPanel features let an account holder's data flow into a query that a root-context process later trusts." That's a harder question to answer from a changelog, which is exactly why staying on a supported update tier with automatic patching matters more than picking through individual advisories after the fact.

Keeping a current cPanel license is what keeps a server eligible to pull these fixes in the first place — a lapsed license doesn't just nag you in WHM, it stops upcp from completing.

Next steps

• cPanel TSR-2026-09-08: prepare for the critical WHM patch — the pre-announcement this advisory follows up on.
• cPanel update tiers explained — why every tier got this patch on the same day.
• CVE-2026-41940: the cPanel & WHM auth bypass — April's unauthenticated root bypass, for comparison.