Security Advisory · Last verified 2026-05-15

cPanel CVE-2026-41940 Self-Check Guide

44,000 servers compromised. 7,135 hit by .sorry ransomware. 1.5 million cPanel instances still reachable on the public internet. A second emergency patch shipped on May 8. Patching alone won't get you out of the hole if your server was up during the two-month zero-day window. Here's the 10-minute self-check I run with clients, using public tools that don't touch your server's authenticated surface.

Verified facts (sources at the bottom)

  • CVE-2026-41940 is a pre-authentication CRLF injection in cPanel/WHM session handling. It gets the attacker authenticated as root without a password, MFA, or anything else. CVSS 9.8 (Critical). Source: NVD, Rapid7, watchTowr Labs, cPanel official advisory.
  • Zero-day window: in-the-wild exploitation since 2026-02-23, around two months before the patch shipped. Source: Help Net Security, KnownHost, XLab/QiAnXin telemetry.
  • Patch released: 2026-04-28, about 28 hours after vendor confirmation.
  • Compromise scale: 44,000 IP addresses on the Shadowserver honeypot list by 2026-04-30. Those are successful exploitations, not just exposed servers.
  • Ransomware: Censys found 8,859 hosts with .sorry-extension files publicly visible. 7,135 of those are confirmed cPanel/WHM servers.
  • Persistent backdoor: the Mr_Rot13 group drops a Go-based cross-platform backdoor called Filemanager. Bcrypt-protected web GUI on a configurable port. XLab calls detection rates "extremely low". C2 domains: wrned[.]com, wpsock[.]com.
  • Still active: as of 2026-05-08, Censys and Shadowserver are still seeing scanning traffic. CISA KEV listing is still live.
  • Second TSR: on 2026-05-08 cPanel shipped fixes for CVE-2026-29201, 29202, 29203. Two emergency TSRs in ten days is unprecedented for this platform.

What CVE-2026-41940 actually does

It's a CRLF injection bug in the basic-authentication path of cPanel/WHM. Two separate code paths write to session files on disk. One sanitises input. The other doesn't. An attacker sends a crafted Authorization header, injects newline-delimited keys into the session file, then on the next request the server treats that session as authenticated as root. No username. No password. No 2FA challenge. Full admin access to the control panel.

cPanel powers about 70 million domains across shared hosting, MSPs, and self-managed VPS users. Shodan reports roughly 1.5 million cPanel instances reachable from the public internet. If your server was up and reachable on 2083 or 2087 between 2026-02-23 and the day your patch landed, you should be treating it as potentially compromised, not just vulnerable. There's a difference.

This guide doesn't include exploit code or proof-of-concept steps. The full technical analysis from watchTowr Labs is linked at the bottom if you need it.

Why patching alone won't save you

cPanel's official tooling has pushed measured patch coverage past 98% in their auto-update channel. That's genuinely impressive vendor work. It's also not the full picture for any individual operator. Here's why.

The patch fixes the bug, not the breach. If your server was reachable between 2026-02-23 and the day your update landed, an attacker may have already dropped the Filemanager backdoor, planted SSH keys, set up cron jobs, exfiltrated bash history, scraped database passwords. Updating cPanel removes the entry door but doesn't evict anyone who's already inside.

Manual-update tiers are slower. CL6/C6, very old branches, and manually-managed fleets get the patch through a different path. Those are over-represented among the 44,000 compromised IPs. If you're on auto-update daily, you're probably fine. If you're not, you're in the at-risk pile.

The CVE pipeline is still hot. Three more critical CVEs (29201, 29202, 29203) shipped on 2026-05-08, ten days after the first one. A control panel that ships two emergency TSRs inside ten days deserves continuous monitoring, not a one-time patch.

So after you patch, you also need an IOC review. The official cPanel detection script is the canonical tool for that, linked in the references.

Who's most exposed

Shared hosting providers running WHM with hundreds or thousands of customer accounts on one server. Small and medium businesses self-managing a single VPS or dedicated box with cPanel exposed on the default ports (2082, 2083, 2086, 2087). Resellers and freelancers managing multiple cPanel servers for clients with outdated installations on legacy machines.

If your cPanel login is reachable from the public internet without IP allow-listing, if you haven't updated in the last few months, or if you can't tell me who logged in last, you're in scope.

10-minute self-check with free public tools

Five steps, all using Ping7's free browser-based tools. They check the publicly observable surface of your cPanel server. Nothing here probes or attacks anything — all five steps just look at information any visitor could already see.

Step 1: Verify the SSL cert on your cPanel HTTPS port

cPanel listens on 2083 for HTTPS. Open Ping7's SSL Checker and enter your domain followed by :2083 if your tooling supports it, or just run the standard HTTPS check on your main hostname.

Three things to confirm: the cert isn't expired and isn't expiring inside 14 days; the Common Name or Subject Alternative Name matches the hostname you actually use to log in; and the cert is signed by a recognised public CA, not a self-signed one.

An expired or mismatched cert isn't the vulnerability. It's a tell that the server has been neglected, which means it's more likely to be running unpatched software too.

Step 2: Check the HTTP status of the cPanel login page

Use Ping7's HTTP Status Checker to fetch the public URL of your cPanel login (something like https://yourdomain.com:2083/). Healthy response is HTTP 200 with a valid TLS handshake.

Red flags: HTTP 5xx errors mean the install is unstable or misconfigured. Reachable from any IP on the internet without an allow-list means you're a target for the port-scanning crowd. Redirects bouncing through unexpected domains is sometimes a sign of compromise already.

Step 3: Inspect HTTP security headers

Open Ping7's HTTP Header Checker and look at the response headers from your cPanel login URL. A current cPanel installation returns at minimum Strict-Transport-Security with a long max-age, X-Content-Type-Options: nosniff, and X-Frame-Options set to deny or sameorigin.

Missing headers don't prove vulnerability to CVE-2026-41940. They do strongly correlate with older installs that probably haven't been patched either.

Step 4: Run WHOIS on the domain

Use Ping7's WHOIS Lookup on the domain pointing at your cPanel server. Confirm registration is current, registrar lock is on, and the contact info matches your records.

Attackers who get into a cPanel server sometimes also try to hijack the associated domain. A WHOIS check is a ten-second sanity test.

Step 5: Check whether your server's IP is blacklisted

Run Ping7's IP Blacklist Check against the public IPv4 of your cPanel server. If the IP shows up on multiple DNSBLs, your server is either sending spam, hosting unwanted content, or otherwise behaving in ways that match a compromise.

Blacklist hits don't always mean a breach. Combined with the other signals here, they mean stop reading and start investigating.

Manual checks on the server

If you have SSH and you're comfortable on the command line, these checks complement the public ones above. Run as root or via sudo.

  • Confirm cPanel version: /usr/local/cpanel/cpanel -V. Compare against the vendor's release notes.
  • cPanel access log for weird logins: tail -200 /usr/local/cpanel/logs/access_log. Look for unfamiliar usernames or source IPs.
  • System auth logs: tail -200 /var/log/secure on RHEL family, /var/log/auth.log on Debian.
  • List cPanel accounts: whmapi1 listaccts. Every account should be one you recognise.
  • cPHulk Brute Force Protection: open WHM, Security Center, cPHulk Brute Force Protection. Confirm it's enabled with reasonable thresholds.

If you find something: act in this order

  1. Patch first. /scripts/upcp --force or the WHM update interface. Closes the underlying vulnerability. Most important step.
  2. Rotate credentials. Force a password reset for every cPanel account on the server, including resellers. Enable 2FA for everything administrative if you haven't already.
  3. Restrict cPanel network access. WHM, Host Access Control. Limit 2082, 2083, 2086, 2087 to known admin IPs. Visitors don't need access to your control panel.
  4. Review auth and access logs. Diff against a known-good period. Unusual times, unfamiliar IPs, successful logins you can't explain. All worth a second look.
  5. Check for new accounts, cron jobs, SSH keys. crontab -l, cat /root/.ssh/authorized_keys, cat /etc/passwd. Quick ways to spot persistence.
  6. If you suspect an active breach, isolate the server. Take it offline or move it behind a firewall before you do anything else. Don't destroy evidence. Snapshot first, cleanup after. If this is deep, you'll want the full recovery playbook.

Long-term hardening

After you patch, this list makes the next vulnerability less likely to land as a breach:

  • Put cPanel behind Cloudflare or another reverse proxy with WAF rules. Free tier is enough for most sites.
  • SSH key auth only. Disable password-based SSH.
  • Strong password policy in WHM. Mandatory 2FA for admins.
  • Weekly automated cPanel updates via WHM, Update Preferences.
  • Centralise cPanel and system logs. Alert on unusual patterns.
  • Periodic external audits against the public attack surface. The five-step check above is a fine starting point and runs in 10 minutes.
  • Offsite immutable backups. A backup an attacker can also encrypt isn't a backup.

Frequently asked questions

How do I check which version of cPanel I'm running?

SSH in and run /usr/local/cpanel/cpanel -V. Compare against the vendor's release notes to confirm whether your install includes the CVE-2026-41940 patch.

Is upgrading cPanel enough to remove the risk?

No. Upgrade closes the vulnerability. It doesn't remove a backdoor that may have been installed during the two-month zero-day window. The Filemanager backdoor used by Mr_Rot13 is designed to evade detection — bcrypt-protected web GUI on a configurable port, statically linked Go binary, persists across reboots and cPanel reinstalls. Run the official cPanel detection script against your session files, rotate every credential on the server, audit cron and SSH keys, look at any binaries with recent mtime. 90-day log review is the floor for due diligence here.

Can I run this self-check without giving anyone access to my server?

Yes. The five public steps only inspect data any visitor can already see — the public TLS certificate, HTTP response headers, WHOIS records, DNSBL listings. None of the Ping7 tools needs credentials or agents.

What if I'm not technical enough to do the manual checks?

Run the five public steps above. For the manual log review and the cPanel upgrade, ask your hosting provider or a security professional. Most reputable hosting providers will do the upgrade for you on request.

Where can I read the official advisory?

Published on the cPanel security advisory page and on NVD. Always cross-reference at least two sources before acting on any third-party security report.

References

Wrap-up

CVE-2026-41940 is serious but recoverable. Ten minutes with a browser is enough to confirm the public surface looks healthy. Patched cPanel, restricted network access, 2FA, clean log review — that combination puts most operators back in a solid spot. If your check turned up red flags, the cPanel recovery playbook is the next read. If you want help with the audit itself, our CVE repair service walks the full check with a senior engineer. The faster you look, the smaller the blast radius of whatever comes next.