{"id":2890,"date":"2026-10-22T14:38:30","date_gmt":"2026-10-22T14:38:30","guid":{"rendered":"https:\/\/hostry.com\/blog\/?p=2890"},"modified":"2026-10-22T15:56:22","modified_gmt":"2026-10-22T15:56:22","slug":"cpanel-cve-2026-41940-patch-lock-down-recover","status":"publish","type":"post","link":"https:\/\/hostry.com\/blog\/cpanel-cve-2026-41940-patch-lock-down-recover\/","title":{"rendered":"CVE-2026-41940 cPanel Flaw: Patch, Lock Down and Recover Your Server"},"content":{"rendered":"\n
\"CVE-2026-41940<\/figure>\n\n\n\n
CVE-2026-41940 let anyone who could reach a cPanel or WHM login page act as the server administrator, and attackers used it for weeks before the April 28, 2026 fix.<\/strong><\/em><\/pre>\n\n\n\n
If you run your own WHM server, the CVE-2026-41940 cPanel<\/strong> fix is only part of the job: you also need to stop exposing the panel to everyone and decide whether the server can still be trusted. On managed cPanel web hosting<\/a><\/strong>, the provider updates the panel for you, but your own passwords and backups are still your responsibility.<\/p>\n\n\n\n
This guide is for administrators of self-managed cPanel & WHM servers and for customers of shared cPanel hosting. It leaves out exploit details and covers only the steps that close the hole and limit the damage.<\/p>\n\n\n\n
CVE-2026-41940 cPanel timeline: what happened<\/h2>\n\n\n\n
On April 28, 2026, cPanel began shipping emergency builds, adding more release lines over the following week, and published its security advisory for CVE-2026-41940<\/a><\/strong>. The 136.0.5 changelog entry<\/a><\/strong> describes the fix in a single line: an issue with session loading and saving. In practice, it was a cPanel authentication bypass<\/strong> that affected cPanel & WHM versions after 11.40, including DNSOnly, and also the WP Squared product.<\/p>\n\n\n\n
The NVD entry<\/a><\/strong> rates it critical: CVSS 3.1: 9.8<\/span> and CVSS 4.0: 9.3<\/span>. CISA added it to the Known Exploited Vulnerabilities catalog on April 30, 2026, two days after the fix. The flaw had already been used as a zero-day, and security firms reported exploitation for weeks before the patch. Earlier start dates have circulated, but they remain unconfirmed.<\/p>\n\n\n\n
The Shadowserver Foundation tracked roughly 44,000 unique IP addresses tied to cPanel exploitation in the days after disclosure. Some providers also reported ransomware activity on compromised servers, although that has not been confirmed as a common outcome.<\/p>\n\n\n\n
Why exposed control panels keep getting hit<\/h2>\n\n\n\n
A hosting control panel is the most valuable login on the machine. WHM can create accounts, edit DNS, read every mailbox and run commands as root. When a flaw in the login and session handling lets the panel treat an anonymous request as an administrator, one bug equals the whole server<\/strong>, plus every website and mailbox on it. Search engines such as Shodan index exposed cPanel and WHM login pages, so attackers can pull a list of candidate servers without running a scan of their own.<\/p>\n\n\n\n
Fast patching could not help during the weeks when no patch existed. A panel that only answered trusted IP addresses could, which is why the steps below keep restricting WHM access<\/strong> in place for good.<\/p>\n\n\n\n
Step 1. Confirm your version and update<\/h2>\n\n\n\n
Start by checking which build the server runs. Log in over SSH as root and run:<\/p>\n\n\n\n
\/usr\/local\/cpanel\/cpanel -V<\/code><\/pre>\n\n\n\n
You can also see the version on the WHM home page. cPanel often prints versions without the leading 11.<\/span>, so 136.0.5<\/span> and 11.136.0.5<\/span> are the same build. Compare your result with the minimum patched builds from the CVE-2026-41940 cPanel advisory:<\/p>\n\n\n\n
Release line<\/th>Minimum patched build<\/th><\/tr><\/thead>
cPanel & WHM 86<\/td>11.86.0.41<\/td><\/tr>
cPanel & WHM 94<\/td>11.94.0.28<\/td><\/tr>
cPanel & WHM 102<\/td>11.102.0.39<\/td><\/tr>
cPanel & WHM 110<\/td>11.110.0.97<\/td><\/tr>
cPanel & WHM 118<\/td>11.118.0.63<\/td><\/tr>
cPanel & WHM 124<\/td>11.124.0.35<\/td><\/tr>
cPanel & WHM 126<\/td>11.126.0.54<\/td><\/tr>
cPanel & WHM 130<\/td>11.130.0.19<\/td><\/tr>
cPanel & WHM 132<\/td>11.132.0.29<\/td><\/tr>
cPanel & WHM 134<\/td>11.134.0.20<\/td><\/tr>
cPanel & WHM 136<\/td>11.136.0.5<\/td><\/tr>
WP Squared<\/td>136.1.7<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Builds released after these are patched too. If your server sits on a line that is not in the table, or on a very old operating system, read the advisory for the exact upgrade path rather than guessing.<\/p>\n\n\n\n
Run the update<\/strong><\/p>\n\n\n\n
In WHM, open Upgrade to Latest Version<\/span> and start the upgrade. From the shell, the same job is done by the update script, followed by a version check and a restart of the panel service:<\/p>\n\n\n\n
\/scripts\/upcp --force\n\/usr\/local\/cpanel\/cpanel -V\n\/scripts\/restartsrv_cpsrvd --hard<\/code><\/pre>\n\n\n\n
The update can take several minutes on a busy server. Run it inside screen<\/span> or tmux<\/span> so a dropped SSH connection does not interrupt it halfway.<\/p>\n\n\n\n
Turn on automatic updates<\/strong><\/p>\n\n\n\n
Go to WHM \u00bb Server Configuration \u00bb Update Preferences<\/span> and set cPanel & WHM updates to automatic on a supported tier. If someone pinned the server to a specific version years ago “for stability”, that pin is now a liability: pinned servers do not receive security builds on their own<\/strong> and must be updated by hand. An automatic update can occasionally change how the panel behaves. In exchange, security builds arrive without anyone having to notice the advisory first.<\/p>\n\n\n\n
Step 2. Stop exposing the panel to the whole internet<\/h2>\n\n\n\n
The CVE-2026-41940 cPanel incident showed that patching alone leaves a gap. cPanel answers on ports 2082\/2083<\/span>, WHM on 2086\/2087<\/span> and Webmail on 2095\/2096<\/span> (plain and TLS in each pair). Few servers need all six open to the world.<\/p>\n\n\n\n
Start with WHM: only you and your team need it, so allow-list your office or VPN addresses and block everyone else. A single-owner server can lock all six ports down; a reseller server may need cPanel open but can still keep WHM private.<\/p>\n\n\n\n
Example with UFW (Ubuntu)<\/strong><\/p>\n\n\n\n
Replace 198.51.100.25<\/span> with your own static IP. Add the allow rules first, then the deny rules, because UFW checks rules in order:<\/p>\n\n\n\n
sudo ufw allow from 198.51.100.25 to any port 2086,2087 proto tcp\nsudo ufw deny 2086,2087\/tcp\nsudo ufw status numbered<\/code><\/pre>\n\n\n\n
Example with CSF<\/strong><\/p>\n\n\n\n
Many cPanel servers still run CSF, now maintained as a community fork. Remove 2086<\/span> and 2087<\/span> from TCP_IN<\/span> in \/etc\/csf\/csf.conf<\/span> (and from TCP6_IN<\/span> if IPv6 is enabled), then allow your address for those ports and reload:<\/p>\n\n\n\n
echo \"tcp|in|d=2087|s=198.51.100.25\" >> \/etc\/csf\/csf.allow\necho \"tcp|in|d=2086|s=198.51.100.25\" >> \/etc\/csf\/csf.allow\ncsf -r<\/code><\/pre>\n\n\n\n
Keep a way back in before you apply any rule.<\/strong> Have a second session open and know how to reach your provider’s web console, in case your home IP changes and you lock yourself out.<\/p>\n\n\n\n
WHM security best practices beyond the firewall<\/h2>\n\n\n\n
None of the settings below would have blocked the CVE-2026-41940 cPanel bypass by itself. Together they make the panel harder to reach and limit what an intruder can do afterwards:<\/p>\n\n\n\n