The cPanel advisory says almost nothing, and on shared hosting the precondition is a paid plan

cPanel has patched CVE-2026-67401, which lets an authenticated account holder with mail-related privileges execute code as root.

Every supported version of cPanel and WHM is affected. The fixed builds:

Reported by Ali Mustafa (rz1027) and abed1526. No public exploit, not in CISA's KEV catalogue, no reported exploitation.

What the advisory does not contain

This is unusually thin, and the gaps are worth listing because each one is a question an administrator has to answer anyway:

• No CVSS score. Nothing to feed a prioritisation process.
• No mechanism. The advisory does not explain how an SQL injection problem becomes file creation and then becomes root access. Three distinct steps, none described.
• No definition of the precondition. "Mail-related privileges" is the stated requirement, and EmailTrack is mentioned, but which privilege level actually qualifies is not said.
• No workaround, unlike previous cPanel advisories.
• No guidance on whether patching removes attacker artefacts from a server already compromised.

A shop deciding whether this is a same-night emergency or a next-window job has been given the affected version list and nothing else to reason with.

On shared hosting, the precondition is the business model

"Requires an authenticated account holder with mail privileges" reads like a constraint. On the population that actually runs cPanel, it is a description of the customer.

Shared hosting puts many unrelated customers on one machine, each with a cPanel account, each with mail. The attacker precondition here is buying a plan — often a few dollars a month, often with no identity verification beyond a payment that can be made with a stolen card.

So the boundary this flaw crosses is not the perimeter. It is the wall between paying tenants, and on the other side of it is root on a box holding every other customer's files, databases and mail.

The WordPress plugin campaigns we covered this week hit the same population from outside. This one starts inside, and it does not need a vulnerability in anybody's website.

The people at risk cannot fix it

Worth stating plainly, because most vulnerability advice assumes the reader controls the software.

If you are a hosting customer, you cannot patch cPanel. You do not have root, you do not choose the build, and you will not be told when it is updated. The only action available to you is to ask, and the only lever is choosing a different host.

If you are a hosting provider, you are the entire mitigation for everyone on your platform, and the flaw is in the tenant boundary you sell.

What to do

If you run the servers:

• Update to the fixed build for your release line — the table above.
• Do not wait for a CVSS score. Root from a tenant account on a multi-tenant box is the severity, whatever number eventually gets attached.
• Audit for artefacts yourself. Nobody has said whether patching cleans a compromised server, so check for unexpected root-owned files, cron entries and SUID binaries with recent timestamps.
• Review which accounts hold mail-related privileges, since that is the stated precondition and it is probably broader than you assume.

If you are a customer:

• Ask your host which cPanel build they are on. A host that answers quickly is telling you something; one that cannot is telling you more.
• Keep your own backups off the platform. This is the general lesson of every shared-hosting incident.

What is not established

• The severity score. None published.
• How the chain works. SQL injection to file creation to root is asserted, not explained.
• Which mail privilege is required.
• Whether patching removes artefacts left by a prior compromise.
• Whether it has been exploited. No reports, no KEV listing.