CVE-2026-65643: a cPanel account can become root on the entire server

In shared hosting, a cPanel account should control only its own domains, files, and databases. CVE-2026-65643 breaks exactly that boundary. According to the advisory cPanel published on August 27, 2026, an authenticated user who can add parked or addon domains can create arbitrary files on the server. Successful exploitation ends in code execution as root, with control over every account, website, and database hosted on the machine.

The public CVE record classifies the flaw as eval injection, CWE-95, and assigns a CVSS 4.0 score of 8.7 with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. The score is high rather than critical because a low-privilege account is required. In the shared-hosting business model, however, providing such an account to a customer is normal product behavior. The prerequisite narrows the attacker population, but it does not reduce the impact of a direct path from tenant to root.

What is confirmed, and what is not

Official sources confirm the entry condition, arbitrary file creation, and the result as root. The CVE record adds the eval-injection classification. They do not publish the vulnerable parameter, the created file path, a request sequence, indicators of compromise, or a proof of concept. Without those details, any specific payload would be speculation. Safe validation therefore begins with version, permission, and feature exposure, without attempting to reconstruct an exploit in production.

• Required attacker: a remote authenticated cPanel user
• Required permission: ability to add parked domains or addon domains
• Confirmed primitive: arbitrary file creation on the server
• Confirmed impact: code execution as root and complete host control
• Interaction by another person: none after the attacker has the account and permission
• Unpublished details: payload, destination file, indicators of compromise, and in-the-wild exploitation status

Why a tenant credential is not a strong barrier

In a typical enterprise application, requiring authentication may restrict a flaw to employees or partners. In shared hosting, the low-privilege account is part of the service being sold. It may belong to a malicious legitimate customer, be opened with a fraudulent identity, leak through phishing, or be taken over through password reuse. Risk testing must use the credential's real acquisition model rather than treating PR:L as a synonym for trusted internal access.

After elevation, account isolation no longer protects the remaining tenants. Root can reach webroots, database configurations, mailboxes, keys, backups, scheduled tasks, and credentials held by local services. cPanel summarizes the impact as control of every account, website, and database on the server. On a host with dozens of customers, the blast radius is therefore defined by server density, not by the size of the account used as the entry point.

CVSS 8.7, critical operational impact

The CVSS 4.0 vector combines a network attack, low complexity, no special attack requirement, and no user interaction with low prior privileges. Confidentiality, integrity, and availability of the vulnerable system all receive high impact. The vector scores no subsequent-system impact, but that does not mean other customers remain protected. Hosted accounts are part of the same system under root authority, and the vendor explicitly states that all of them become reachable.

This is a case where the number must be read alongside the business model. A filter that prioritizes only CVEs above 9.0 may place this flaw behind issues with no realistic path to production. For a provider with open registration, resellers, or many third-party-managed accounts, the combination of an attainable credential and total impact warrants emergency treatment even with an 8.7 base score.

Patched versions and how to confirm the update

cPanel states that all supported versions were affected and publishes a patched build for each release line. The CVE summary mentions 11.138.0.0 and earlier, but that short description should not be turned into one cutoff across every branch. For remediation, compare the installation with the matching line in the vendor table and update to one of the builds below or later.

• cPanel & WHM 11.110: build 11.110.0.141 or later
• cPanel & WHM 11.134: build 11.134.0.53 or later
• cPanel & WHM 11.136: build 11.136.0.37 or later
• cPanel & WHM 11.138: build 11.138.0.2 or later
• WP Squared, identified as WP2 in the advisory: build 11.138.1.7 or later
• Unsupported versions: migrate to a supported release line first, because EOL versions do not receive security fixes

# Check the version that is actually installed
/usr/local/cpanel/cpanel -V

# As root, apply the update recommended by cPanel
/usr/local/cpanel/scripts/upcp --force

# Confirm the version again after the update
/usr/local/cpanel/cpanel -V

It is not enough to confirm that a repository or update policy points to a safe release line. The evidence is the version returned on the host after execution. Across fleets, collect that result per server and treat any node that does not respond as pending, because one forgotten panel preserves the path to every tenant on that machine.

Triage without ready-made indicators

The patch closes the vulnerable condition, but it does not prove the server was never used. Because the advisory provides no indicators of compromise, the investigation must begin with confirmed behavior: sessions from accounts able to manage domains, unexpected parked or addon-domain additions, files outside the tenant's expected space, and any later persistence with root privileges. Preserve logs and a snapshot before removing artifacts.

# Inventory accounts on the host
whmapi1 --output=jsonpretty listaccts

# For each relevant account, list every known domain
uapi --output=jsonpretty --user=CPUSER DomainInfo list_domains

# Review recent sessions for the account under investigation
grep 'CPUSER' /usr/local/cpanel/logs/session_log | grep NEW | tail -n 50

# List altered cPanel-managed packages
/usr/local/cpanel/scripts/check_cpanel_pkgs --list-only

• Correlate recent sessions with domain changes requested by the customer or operations team
• Compare current aliases, addon domains, and document roots with inventory, tickets, and earlier backups
• Review new administrative users, SSH keys, cron jobs, services, web shells, and webroot changes
• Audit database access, exports, grant changes, and use of credentials stored on the host
• Rotate passwords, tokens, and keys reachable from the server when compromise is suspected
• Expand incident response to every tenant on the host rather than limiting analysis to the initiating account

What to test in hosting control panels

A cPanel environment pentest should not assess only each customer's website. The panel is the control plane and needs an explicit multi-tenant isolation objective. With a lower-privilege account supplied for testing, we determine which functions alter global configuration, where domain names and paths reach the filesystem, which privileged processes consume that data, and whether one tenant can cause an effect outside its own directory. In production, validation should use harmless markers and stop before any attempt to obtain root.

• Separation among cPanel account, reseller, WHM, and root
• Authorization to create parked domains, addon domains, subdomains, and document roots
• Path canonicalization, symlinks, and destinations written by privileged processes
• Data validation before values reach templates, interpreters, or dynamic calls
• Filesystem, database, email, backup, and secret isolation among tenants
• Logs that attribute each domain change to the correct session, account, and source
• Detection of file creation and privileged execution originating from self-service flows

The lesson for pentest buyers

CVE-2026-65643 shows why scope must follow trust boundaries, not just URLs. A hosting portal may look like an auxiliary administrative system, but it coordinates privileged processes and concentrates access to dozens of environments. If testing covers only published applications and leaves the panel out, the main path between one customer and every other customer remains unvalidated.

The immediate action is objective: identify the installed release line, apply the matching patched build, and confirm the version on every server. Then review domain activity and persistence signals according to actual account exposure. In the next pentest, treat cPanel and any other multi-tenant control plane as a maximum-impact asset, even when exploitation begins with a low-privilege credential.