Critical cPanel & WHM Authentication Vulnerability: What Every User Must Do Right Now

If your digital property runs on a shared or managed hosting environment that uses cPanel and WHM, you need to stop and read this. A critical authentication vulnerability has just been disclosed in cPanel & WHM, the control panel software powering millions of hosting accounts worldwide.

What Happened

cPanel’s own security team has confirmed a critical flaw in the login authentication mechanism affecting all currently supported versions of cPanel and WHM. In plain language: an attacker who knows how to exploit this vulnerability doesn’t need your password. They can bypass the login process entirely.

The affected entry points are:

• Port 2083 / 2082 — cPanel (your regular hosting dashboard)
• Port 2087 / 2086 — WHM (the server-level admin panel used by resellers and admins)
• Port 2095 / 2096 — Webmail
• Port 2077 / 2078 — WebDisk (if enabled)

If any of those ports are publicly accessible on your server right now, you have a window of exposure that bad actors are likely already probing.

Why This Is Especially Dangerous for Online Businesses

Most website owners think of their hosting panel as a background utility, like something you log into once a month to renew an SSL cert or check disk space. However, your cPanel or WHM is essentially the master key to your entire digital operation.

Gaining unauthorized access means an attacker can:

• Install malware or backdoors directly into your site files
• Harvest all email accounts and correspondence
• Redirect your domain DNS to phishing pages
• Extract your databases — customer records, orders, credentials
• Silently add cron jobs that persist even after a “cleanup.”
• Pivot to compromise other accounts on shared servers

For business owners managing client sites, resellers operating WHM instances, or agencies running multi-tenant environments, the blast radius here is enormous.

Immediate Steps to Take Right Now

UPDATE: cPanel has launched a patch for all supported versions.

We have pushed out a patch for the following versions: 

TIER 11.110   WAS: 11.110.0.96      NOW: 11.110.0.97
TIER 11.118   WAS: 11.118.0.61      NOW: 11.118.0.63
TIER 11.126   WAS: 11.126.0.53      NOW: 11.126.0.54
TIER 11.132   WAS: 11.132.0.27      NOW: 11.132.0.29
TIER 11.134   WAS: 11.134.0.19      NOW: 11.134.0.20
TIER 11.136   WAS: 11.136.0.4.      NOW: 11.136.0.5

Please run the following command to retrieve the patched version. 

/scripts/upcp

Warning: If your server is not running a supported version of cPanel eligible for this update, it is highly recommended that you update your server as soon as possible, as it is likely also affected by this issue. 

The following steps are no longer necessary, as the cPanel security team has fixed the vulnerability and provided an updated version that patch your system.

Until it’s deployed, their security team has updated the official workaround with a clearer priority order. Follow these steps in sequence — start with Step 1 and only move to Step 2 if you can’t execute Step 1.

1. Stop the Vulnerable Services Directly (Primary Recommendation)

This is now the preferred mitigation. Rather than blocking ports and locking everyone out of the panel entirely, you can surgically turn off the two services at the heart of the exploit.

First, disable cpdavd (the WebDisk daemon):

whmapi1 configureservice service=cpdavd enabled=0 monitored=0

Then stop cpsrvd (the core cPanel service daemon):

/scripts/restartsrv_cpsrvd --stop

This is the cleanest option available right now. It neutralizes the attack surface without a full panel lockout. If you have SSH access to your server, this should be your first move.

2. Block cPanel Ports at the Firewall Level (Fallback if Step 1 Isn’t Possible)

If you cannot turn off those services — for example, because you’re on managed hosting without shell access — fall back to firewall-level blocking of all cPanel TCP ports:

• 2083 / 2082 — cPanel (SSL and non-SSL)
• 2087 / 2086 — WHM (SSL and non-SSL)
• 2095 / 2096 — Webmail
• 2077 / 2078 — WebDisk (if enabled)

Use CSF, iptables, or your hosting provider’s firewall UI to block inbound traffic on these ports. Be aware: this locks out all panel access, including your own, until the patch is applied. It’s a blunt instrument, but it works.

3. Disable Service/Proxy Subdomains (Do This Regardless)

Whether you took Step 1 or Step 2, also close off the proxy subdomain attack surface — entry points like cpanel.yourdomain.com and webmail.yourdomain.com that can bypass port-level blocking. Run:

whmapi1 set_tweaksetting key=proxysubdomains value=0 && /scripts/proxydomains remove && /scripts/rebuildhttpdconf && /scripts/restartsrv_httpd

Alternatively, this can be toggled manually via WHM under Tweak Settings → Proxy Subdomains if you still have panel access.

The logic is simple: stop the services if you can, block the ports if you can’t, and kill proxy subdomains either way. Don’t wait for your host to notify you — verify with them directly that one of these mitigations is in place on your server today.

Lessons Every Business Should Internalize

This vulnerability is a reminder that the attack surface of a modern online business extends far beyond your front-end application.

Here are the principles I advise every operator I work with to build into their infrastructure:

• Restrict Panel Access by IP. WHM and cPanel should never be publicly accessible from any IP on the internet. Allow your home IP, VPN IP, or office range. Everything else should be blocked at all times — not just during emergencies.
• Audit Who Has Access. When did you last check which accounts have WHM reseller access? Which email accounts are configured? Most breaches don’t come through zero-days — they come through forgotten accounts with weak passwords.
• Separate Your Environments. Your highest-value client sites should not coexist on the same server as your experimental projects or old staging environments. Segmentation limits blast radius.
• Monitor Login Attempts. Tools like cPHulk (built into WHM) and external log aggregators can alert you to brute-force patterns before they escalate into successful attacks. Set them up and actually review the alerts.
• Maintain Offline Backups. If an attacker does get in and corrupts or encrypts your files, your recovery path is only as strong as your last clean backup stored somewhere they cannot reach. “JetBackup to the same server” is not a backup strategy.
• Subscribe to Security Feeds. The cPanel security advisory for this vulnerability was published on their support portal. If you weren’t notified within hours, you don’t have the right monitoring in place. Subscribe to cPanel’s release notes, follow security researchers on X/Twitter, and set up Google Alerts for your critical infrastructure vendors.

Final Thought

The businesses that survive security incidents are rarely the ones with the most sophisticated defenses. They’re the ones that respond fastest when a vulnerability is disclosed and have the operational discipline to reduce their attack surface before the incident.

This cPanel vulnerability is a real and present risk. till the patch’s released.

Act now, patch when available, and then audit everything.