Search for a command to run...
No comments yet. Be the first to comment.
A few months back I was doing passive recon on a fintech startup as part of some responsible disclosure research. Nothing crazy — subdomain enumeration, checking for exposed admin panels, the usual. One of the subdomains came back with a live cPanel login page on port 2087, publicly accessible to anyone on the internet.
I flagged it in my disclosure report and moved on. Hosting control panels exposed to the public internet aren't unusual, but they're never a good look — especially for a company handling financial data.
Then CVE-2026-41940 dropped.
On April 28 2026, cPanel pushed an emergency patch for a critical authentication bypass affecting all supported versions of cPanel and WHM. CVSS 9.8. The kind of score that means drop everything and patch.
The vulnerability had already been exploited in the wild since at least February 23 — 64 days before anyone publicly knew it existed.
By the time the patch came out, ransomware operators were already running automated campaigns against exposed instances. A group deploying "Sorry" ransomware hit thousands of servers within days of public disclosure. KnownHost, Namecheap, and other major hosting providers had to block ports 2083 and 2087 entirely just to buy time to patch their fleets.
The numbers are brutal. Around 1.5 million cPanel instances are exposed on the internet. At least 44,000 IPs were confirmed compromised in the first wave.
CVE-2026-41940 is a CRLF injection flaw in how cPanel handles the login flow. Here's what actually happens:
When you attempt to log in, cPanel's service daemon (cpsrvd) writes data from your request into a server-side session file before it verifies your credentials. That's the root cause — user input hits disk before authentication runs.
An attacker exploits this in four steps:
Stage 1 — Send a login request with invalid credentials. This fails, but cPanel still issues a whostmgrsession cookie for the pre-authentication session.
Stage 2 — Send a GET request with a crafted Authorization header containing CRLF characters (\r\n). cPanel fails to sanitize these, so the injected data gets written directly into the session file. The payload promotes the session to root by injecting:
user=root
hasroot=1
tfa_verified=1
successful_internal_auth_with_timestamp=9999999999
Stage 3 — Hit /scripts2/listaccts to trigger a session file reload. This causes cPanel to re-parse the now-poisoned session file and load the injected root credentials into the active session cache.
Stage 4 — You now have an authenticated root WHM session. No password. No 2FA. Full administrative access to the server, every hosted site, every database, every email account on it.
The entire chain is four HTTP requests.
Something that got underreported in the initial coverage: a lot of these exposed cPanel instances are shared hosting servers.
When I ran my tool against the startup I'd previously disclosed to, the canonical hostname resolved to a third-party hosting provider — not the startup's own infrastructure. That one server was hosting potentially hundreds of tenants.
If that server is vulnerable, it's not just one company's problem. Every site on that box is exposed. The blast radius for a single unpatched shared hosting server isn't one victim — it's every customer on the platform.
This is what makes CVE-2026-41940 a systemic issue, not just a patch management problem. cPanel controls somewhere north of 70 million domains. A single vulnerability in a platform with that kind of market concentration is essentially an attack on a significant chunk of the internet's hosting infrastructure.
After the CVE dropped I built a detection and exploitation tool for authorized red team use. It handles:
Passive version fingerprinting via unauthenticated endpoints and asset timestamp analysis
Shared hosting detection with blast radius warning
Full 4-stage exploit chain for authorized engagements
Post-exploitation enumeration (read-only)
Optional command execution for impact demonstration
Detect-only mode is the default — it never touches the authentication flow. You have to explicitly pass --exploit to run the chain.
# detect only
python3 cp.py -t cpanel.target.com
# full chain (authorized use only)
python3 cp.py -t cpanel.target.com --exploit
# with command execution
python3 cp.py -t cpanel.target.com --exploit --exec "id; whoami; hostname"
Tool is on GitHub: github.com/nickpaulsec
If you're running cPanel or WHM, check your version against these patched thresholds:
| Branch | Patched Version |
|---|---|
| 11.110.x | 11.110.0.97+ |
| 11.118.x | 11.118.0.63+ |
| 11.126.x | 11.126.0.54+ |
| 11.132.x | 11.132.0.29+ |
| 11.134.x | 11.134.0.20+ |
| 11.136.x | 11.136.0.5+ |
If you're on a hosting provider, contact them and ask for confirmation that the patch has been applied. Don't assume auto-updates ran.
Check for IOCs:
Look in /var/cpanel/sessions/raw/ for session files with multiple pass= lines or user=root on a non-root session
Review access logs for unexpected root sessions going back to February 23
Check for unexpected SSH keys, cron jobs, or new accounts
Exploitation leaves traces but only if you know where to look. If your server was internet-exposed during the pre-disclosure window and you haven't checked yet, assume compromise until proven otherwise.
The startup I originally disclosed to? I sent them a follow-up. Their hosting provider had already patched. But the fact that their control panel was publicly accessible at all is still a problem — CVE-2026-41940 is patched, but the next one won't be.
Restrict port 2087 to trusted IPs. That's the real fix.