cPanel & WHM Domain Parking Arbitrary File Creation to Root RCE

CVE-2026-65643 is an arbitrary-file-creation flaw in cPanel & WHM's domain parking / addon-domain subsystem. Any authenticated cPanel account holder with the routine permission to add parked or addon domains — a permission enabled by default on virtually every shared-hosting plan — can write files to arbitrary paths on the underlying Linux server. Because cPanel's internal daemons run privileged operations on behalf of accounts, this file-write primitive escalates to code execution as root, giving the attacker unrestricted control over every site, database, email account, and SSL key hosted on that machine. All supported cPanel & WHM release tiers are affected: 110.x, 134.x, 136.x, and 138.x prior to the patched builds (11.110.0.141, 11.134.0.53, 11.136.0.37, 11.138.0.2, WP² 11.138.1.7).

No vendor CVSS score has been published — cPanel's advisory carried no numeric rating, and no CVE record existed in the CVE Program's store as of August 28, 2026. That silence radically understates the risk. The authentication prerequisite sounds like friction until you remember the deployment model: on shared hosting, *anyone* can buy a $5/month account and receive a cPanel login with domain-parking privileges. This is not 'authenticated access' in the enterprise sense — it is open enrollment. Combined with a blast radius that spans every tenant on the server (often hundreds of sites), the real-world severity is squarely CRITICAL.

Why this verdict

• Near-zero auth friction on shared hosting: The 'authenticated' prerequisite is meaningless in cPanel's primary deployment model. Anyone can buy a hosting account for a few dollars and receive full domain-parking privileges. This is not enterprise authentication — it is open enrollment.
• Role multiplier: cPanel/WHM is canonically a multi-tenant hosting platform. Each server typically hosts 50–500 customer websites, databases, and email accounts. Root compromise = full tenant-to-tenant breach across the entire server. On reseller plans, WHM API tokens may enable lateral movement to additional servers. Blast radius: tenant → all tenants → potentially fleet via reseller chains.
• Massive exposure surface: ~650,000 cPanel instances are directly internet-exposed per Shodan telemetry, collectively hosting tens of millions of websites. Domain parking is enabled by default, making the vulnerable code path reachable on virtually every installation.
• All supported versions affected: There is no 'safe' version prior to the patch. Every cPanel server in production is vulnerable until updated.
• Simple primitive, fast weaponization expected: Arbitrary file write to root-controlled paths is a well-understood escalation pattern on Linux. The patch diff will be trivially reversible. Expect weaponized exploits within days to weeks.

Why not higher?

A score of 9.4 is near the ceiling. The only reason it isn't 10.0 is that the attack does require *some* form of authentication — even though it's trivially obtainable on shared hosting, on dedicated/VPS servers where the cPanel user *is* the server owner, the multi-tenant escalation angle doesn't apply. This narrows the worst-case population slightly.

Why not lower?

Downgrading below CRITICAL would require ignoring cPanel's canonical deployment context. The 'requires authentication' label is technically true but practically meaningless on shared hosting — the dominant use case. The blast radius (hundreds of co-tenants per server), the exposure surface (650K+ internet-facing instances), the all-versions scope, and the simplicity of the file-write-to-root primitive all reinforce CRITICAL. No combination of friction points justifies HIGH or below.

1. Patch immediately via /scripts/upcp --force — This is the only complete fix. Run on every cPanel server within the noisgate CRITICAL mitigation SLA of 3 days. The update is non-disruptive and takes 5–15 minutes per server. Automate across your fleet with Ansible/SSH loops.
2. Disable domain parking and addon domains — As an interim control before patching, disable the domain-parking and addon-domain features at the WHM level (Tweak Settings → Domains → Allow addon domains = Off; Allow parked domains = Off). This removes the attack surface but breaks legitimate customer workflows — use only as a bridge to patching. Reclaim Hosting confirmed they applied this control within hours of disclosure.
3. Enable and enforce SELinux in enforcing mode — SELinux enforcing with the cPanel-targeted policy can prevent the cPanel daemon from writing to unexpected filesystem paths like /etc/cron.d/. This is a defense-in-depth layer — it may not fully block the exploit but raises the bar significantly. Most shared-hosting providers run SELinux disabled; turning it on requires testing.
4. Deploy file integrity monitoring on critical paths — Configure AIDE, OSSEC, or Wazuh to monitor /etc/cron.d/, /var/spool/cron/, /usr/local/cpanel/hooks/, and all cPanel template directories. Alert on any file creation or modification outside expected change windows. This won't prevent exploitation but ensures rapid detection.
5. Audit and restrict cPanel account provisioning — Review automated account creation pipelines. If you operate a reseller or WHMCS-based provisioning system, temporarily gate new account creation behind manual approval to prevent attackers from rapidly spinning up accounts for exploitation.

Run this script on each cPanel/WHM server as root. It checks the installed cPanel build number against the patched versions. Example: sudo bash cpanel_cve_2026_65643_check.sh. No external dependencies required.

#!/usr/bin/env bash
# CVE-2026-65643 Vulnerability Check for cPanel & WHM
# Run as root on the target cPanel server.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

if [ "$(id -u)" -ne 0 ]; then
  echo "[!] Must run as root."
  exit 2
fi

if ! command -v /usr/local/cpanel/cpanel &>/dev/null; then
  echo "UNKNOWN — cPanel is not installed on this host."
  exit 2
fi

# Get the full build version string, e.g., 11.138.0.2
BUILD=$(/usr/local/cpanel/cpanel -V 2>/dev/null | grep -oP '[\d]+\.[\d]+\.[\d]+\.[\d]+')

if [ -z "$BUILD" ]; then
  echo "UNKNOWN — Could not determine cPanel version."
  exit 2
fi

echo "[*] Detected cPanel build: $BUILD"

# Parse version components
IFS='.' read -r MAJOR MINOR PATCH REVISION <<< "$BUILD"
TIER="${MAJOR}.${MINOR}"

# Patched versions per tier:
#   11.110 >= 11.110.0.141
#   11.134 >= 11.134.0.53
#   11.136 >= 11.136.0.37
#   11.138 >= 11.138.0.2 (or WP2: 11.138.1.7)

check_patched() {
  local need_patch="$1" need_rev="$2"
  if [ "$PATCH" -gt "$need_patch" ]; then
    return 0
  elif [ "$PATCH" -eq "$need_patch" ] && [ "$REVISION" -ge "$need_rev" ]; then
    return 0
  fi
  return 1
}

case "$TIER" in
  11.110)
    if check_patched 0 141; then
      echo "PATCHED — $BUILD >= 11.110.0.141"
      exit 0
    else
      echo "VULNERABLE — $BUILD is below 11.110.0.141. Update immediately: /scripts/upcp --force"
      exit 1
    fi
    ;;
  11.134)
    if check_patched 0 53; then
      echo "PATCHED — $BUILD >= 11.134.0.53"
      exit 0
    else
      echo "VULNERABLE — $BUILD is below 11.134.0.53. Update immediately: /scripts/upcp --force"
      exit 1
    fi
    ;;
  11.136)
    if check_patched 0 37; then
      echo "PATCHED — $BUILD >= 11.136.0.37"
      exit 0
    else
      echo "VULNERABLE — $BUILD is below 11.136.0.37. Update immediately: /scripts/upcp --force"
      exit 1
    fi
    ;;
  11.138)
    # Check both main (0.2) and WP2 (1.7) tiers
    if [ "$PATCH" -ge 2 ]; then
      echo "PATCHED — $BUILD >= 11.138.0.2"
      exit 0
    elif [ "$PATCH" -eq 1 ] && [ "$REVISION" -ge 7 ]; then
      echo "PATCHED — $BUILD >= 11.138.1.7 (WP2)"
      exit 0
    elif [ "$PATCH" -eq 0 ] && [ "$REVISION" -ge 2 ]; then
      echo "PATCHED — $BUILD >= 11.138.0.2"
      exit 0
    else
      echo "VULNERABLE — $BUILD is below 11.138.0.2 / 11.138.1.7. Update immediately: /scripts/upcp --force"
      exit 1
    fi
    ;;
  *)
    echo "UNKNOWN — Tier $TIER is not in the known affected/patched list. Verify manually."
    exit 2
    ;;
esac

Sources

1. The Hacker News — Critical cPanel Flaw Coverage
2. CyberSecurity News — cPanel Vulnerability Analysis
3. GBHackers — cPanel Root Control Vulnerability
4. Reclaim Hosting — CVE-2026-65643 Customer Advisory
5. RankiTeo — cPanel Vulnerability August 2026
6. LowEndTalk — Community Discussion on cPanel Flaw
7. Picus Security — cPanel Exposure Data (CVE-2026-41940 context)