cPanel and Plesk Both Patched a Root Escalation the Same Day

Two Advisories, One Day

On August 27, 2026, cPanel and Plesk each published a fix for the same class of problem: an ordinary customer account on a shared server escalating to root.

Read side by side they look interchangeable. They are not, and the difference decides whether you are exposed.

cPanel: CVE-2026-65643

cPanel's advisory describes it in one sentence:

An authenticated cPanel account holder who is able to add parked or addon domains can create arbitrary files on the server.

The impact is stated just as plainly:

Successful exploitation leads to code execution as the root user, giving an attacker full control of the server and every account, website, and database on it.

All supported versions are affected. The patched builds are 11.110.0.141, 11.134.0.53, 11.136.0.37, 11.138.0.2 and, for WP2, 11.138.1.7, in each case that version or later.

The uncomfortable part is the prerequisite, because there barely is one. Parked and addon domains are how a customer points a second domain name at a site they already have. It is a routine feature, enabled on essentially every shared and reseller server, and it is not a privilege anyone thinks of as sensitive. On a box with fifty customers, the honest assumption is that fifty accounts can reach this.

cPanel published no CVSS score and no report of exploitation in the wild. The advisory does not need either to be urgent.

Plesk: CVE-2026-67394

Plesk's wording:

A security vulnerability CVE-2026-67394 was discovered in Plesk that could allow a customer or reseller to escalate privileges to root on the server.

Affected are Plesk for Linux 18.0.34 through 18.0.79.8 and 18.0.80 through 18.0.80.4. The fixes are 18.0.79.9 and 18.0.80.5, shipped as Obsidian 18.0.79 Update 9 and 18.0.80 Update 5. The vulnerability was reported by Aziz Knani.

Two facts here change the picture completely, and both are easy to miss in a summary.

Plesk for Windows is not affected at all. Plesk's own table says so outright.

The Linux bug needs shell access. The exploitation condition is a customer or reseller account that has shell access, or that is allowed to change its own shell access. Plesk is explicit about what follows:

No mitigation is possible if shell access is required. Update to resolve such cases. If shell access is not required by the customers or resellers, it can be disabled to block exploits.

That is a genuinely useful sentence. If your customers do not get shell, you have a switch that closes this without a maintenance window, and you can patch on your own schedule rather than at eleven at night.

So Who Is Actually At Risk

Put the two next to each other and the asymmetry is the whole story.

	cPanel CVE-2026-65643	Plesk CVE-2026-67394
What an attacker needs	A normal account that can add a parked or addon domain	Shell access, or the right to grant themselves shell
Typical shared server	Almost every customer qualifies	Often nobody qualifies
Windows	Not applicable	Not affected
Mitigation without patching	None	Disable shell access

On the cPanel side there is no clever answer. The feature that carries the bug is one your customers use on purpose, and taking it away breaks the product. Update.

On the Plesk side, check before you panic. If shell is off for customers and resellers, and they cannot turn it on themselves, the exploit path is closed today and the update is ordinary maintenance rather than an emergency.

What To Do This Week

Find out what you are running. Not what you think you deployed, what the box reports. Both vendors give a version check, and across a fleet the answer is usually less uniform than anyone expects.

Patch, then verify. Automatic updates are a plan, not a result. Confirm the running build afterwards rather than trusting that the update window did its job. Both advisories name exact version numbers precisely so you can check.

On Plesk, audit shell access as a separate task. Whether or not it saves you here, knowing which customers hold shell on which servers is worth having written down. It is the kind of question that only ever gets asked during an incident.

Look at what a root compromise would have reached. Root on a shared server is root over every tenant on it. If one machine holds fifty sites and one database server, that is the blast radius, and this is a good week to notice it rather than a bad one.

The Pattern Worth Noticing

This is not the first control panel escalation this month. On August 4, cPanel patched CVE-2026-58048, a database privilege escalation that also turned a valid login into more than it should be.

The shape repeats because the job is hard. A control panel exists to let an untrusted customer perform root-level operations through a narrow, safe interface. Every feature is another place where that boundary has to hold, and a hosting panel has hundreds of features. Vendors patching quickly is the system working, and it only works if the patch reaches your servers.

We keep cPanel servers and Plesk servers patched and monitored for teams who would rather not read advisories on a Thursday evening, and handle security and compliance work more broadly. If you are not sure what your fleet is running, get in touch.

Sources: cPanel advisory for CVE-2026-65643, August 27 2026, Plesk advisory for CVE-2026-67394