SURIQ
cPanel has spent the last two months patching the same class of bug: a paying customer with an ordinary hosting account finding a path to root on the box everyone else on that server shares. CVE-2026-65643 is the newest entry, and it may be the cleanest one yet. A customer who is allowed to add a parked or addon domain can write a file anywhere on the filesystem, and that write turns into code execution as root. Full control of the machine, from an account that costs a few dollars a month.
cPanel disclosed the flaw in an advisory published on August 27, 2026, and rated it critical. It affects every supported version of cPanel and WHM. There is no public proof-of-concept and no report of exploitation in the wild yet, and as of the advisory it was not on CISA's Known Exploited Vulnerabilities list. That is the good news. The bad news is the precondition. A working hosting account is not a barrier on the shared and reseller servers where cPanel lives.
What CVE-2026-65643 lets an attacker do
The flaw sits in the domain parking and addon domain feature, the part of cPanel that lets an account point extra domains at an existing site. According to cPanel's advisory, any logged-in customer whose account is allowed to set up a parked or addon domain can write files to any location on disk, and a successful attempt runs code as root. Root is the whole server: every other customer's files, databases, mail, and stored credentials on that host.
No CVSS score shipped with the advisory, but "authenticated low-privilege user reaches root" is about as severe as a local flaw gets. The fix lands in a set of patched builds, one per supported release branch.
| Release branch | First patched build |
|---|---|
| 11.110 | 11.110.0.141 |
| 11.134 | 11.134.0.53 |
| 11.136 | 11.136.0.37 |
| 11.138 | 11.138.0.2 |
| WP Squared | 11.138.1.7 |
End-of-life branches get no fix. If your server runs one, the only route to safety is upgrading to a supported branch and then to its patched build.
On shared hosting, "authenticated" is not a wall
The detail that changes the risk is who counts as an attacker. On a single-tenant server you control every account, so an authenticated flaw is mostly an insider or post-compromise concern. Shared and reseller hosting inverts that. The server's whole business model is selling authenticated accounts to strangers. Anyone with a card and a few dollars gets exactly the precondition this bug needs, which makes it behave much more like a pre-authentication flaw in practice. The attacker does not need to break in. They sign up.
Reseller environments push it further, because one oversold plan can hold hundreds of low-trust accounts, any of which could be the one that pivots to root and reaches every neighbor on the node. A phished or credential-stuffed customer account gives an outside attacker the same launch point without paying for it.
This is a pattern, not a one-off
We have tracked several cPanel-adjacent privilege escalations in quick succession. This month we covered a cPanel flaw that let a hosting account reach database root, and before it a LiteSpeed cPanel plugin that handed shared-hosting tenants root twice in one year. The Control Web Panel story was the same shape from a different vendor: a public exploit that hijacks unpatched servers with no password. cPanel also shipped a multi-flaw security release over the summer.
The through-line is that the control panel is the highest-value target on a hosting box, and its features run with enough privilege that a bug in an everyday function collapses the boundary between one tenant and the entire machine. If you operate multi-tenant hosting, treat "low-privilege account to root" as a recurring category, not a string of unrelated CVEs, and build your patch cadence and your detection around it. This is exactly the kind of exposure continuous vulnerability detection exists to surface before an attacker does.
Patch, then check whether the window was used
Patching is the first move and it is simple. If your server is on cPanel's automatic daily update track, the fixed build arrives on its own. Many production hosts are not on that track: operators who stage or pin updates to avoid surprise breakage are precisely the ones still exposed after this advisory, so do not assume auto-update has you covered. To force it now, run /scripts/upcp --force or use WHM's upgrade screen, then confirm the build number matches the patched release for your branch.
If you cannot patch every server this hour, the interim step is to limit who can trigger the vulnerable feature. Restrict parked and addon domain permissions and review which accounts currently hold them, especially on reseller nodes. That shrinks the set of accounts that can reach the bug while the update rolls out.
Patching closes the hole. It does not tell you whether anyone walked through it first. Because exploitation ends in an arbitrary file written as root, the signal to hunt for is a root-owned file appearing somewhere cPanel and your package manager never put one, or a file creation that lines up with a parked or addon domain operation in the account logs. This is what file integrity monitoring is for: watch the paths root owns and alert on writes that no package or admin action explains. On a shared box, that one detection is worth more than any single CVE, because the next tenant-to-root bug will look the same on disk.