CVE-2026-41940: cPanel and WHM Auth Bypass, Fixed Builds and Checks

CVE-2026-41940 is a critical authentication bypass in cPanel and WHM, and in WP Squared, that lets an unauthenticated remote attacker into the control panel, up to root-level WHM. cPanel says every version after 11.40 is affected until the patched builds it released on 28 April 2026. Update with /scripts/upcp --force, restart cpsrvd, then run cPanel's detection script.

Looking for PHP2Shell (CVE-2026-109618 and CVE-2026-109619)? That is a different, newer flaw, in PHP itself rather than in cPanel. cPanel shipped fixed ea-php packages on 21 October 2026, including backports for ea-php74, ea-php80 and ea-php81. My PHP2Shell guide explains how it works and how to patch and verify a cPanel server.

What is CVE-2026-41940 in cPanel and WHM?

It is a flaw in how cpsrvd, the cPanel service daemon, writes login session files, which lets a crafted request turn an unauthenticated session into an authenticated one. cPanel's response post says two code paths write session files to disk, and the one used during Basic authentication handling skipped an input-sanitizing step. Rapid7's write-up calls it a CRLF injection: carriage-return and line-feed characters in a malicious Basic authorization header end up in the session file, so an attacker can add a line such as user=root, reload the session and act as an administrator.

Which cPanel and WHM versions are affected, and which builds fix it?

Every cPanel and WHM version after 11.40 is affected until it reaches the first patched build of its major version. The table copies cPanel's security advisory for CVE-2026-41940 as I read it on 12 October 2026. A server is fixed when it runs the build shown or a later build of the same major version. The advisory adds that all later cPanel versions are patched too.

If your major version is not in the table, it has no patched build of its own. Move to a listed version or a newer one.

Where the published version lists differ

• Arctic Wolf and Rapid7 list eight fixed builds, without 11.94, 11.102 and 11.124. They wrote on 29 and 30 April, before cPanel added those.
• NVD's machine-readable configuration marks every build from 88.0.0 up to 110.0.97 as vulnerable, ignoring the 11.94 and 11.102 fixes. VulnCheck's version data on the same record matches cPanel.
• Help Net Security wrote that WP Squared v136.1.7 is affected. cPanel says 136.1.7 is the fixed version, and its response post says WP Squared is affected up to 11.136.1.6.
• CISA's catalog dates the KEV listing 30 April. cPanel's response post says 1 May.

cPanel's advisory is the authoritative list. It has been edited more than a dozen times, so re-read it instead of trusting a copy, including this one.

How do I check which cPanel build my server runs?

Run /usr/local/cpanel/cpanel -V as root. It prints the major version and build, for example 110.0 (build 97), which is 11.110.0.97 in the advisory's notation. cPanel's version numbering documentation explains the leading 11 as a legacy parent value and the 0 as a minor value that never changes.

/usr/local/cpanel/cpanel -V        # e.g. 136.0 (build 5)
cat /usr/local/cpanel/version      # e.g. 11.136.0.5
whmapi1 version                    # the same through the WHM API
grep CPANEL= /etc/cpupdate.conf    # release tier, or a pinned build number

The last line matters most. A tier name such as STABLE or RELEASE means the server follows that tier. A version number means it is pinned. cPanel's Update Preferences documentation says the hourly security-update cron takes no action when the server is set to a specific numbered version or the update repository is disabled. The advisory makes the same point: pinned servers and servers with updates turned off need a manual update.

How do I update cPanel and WHM to a fixed build?

Run the update script with --force, confirm the build, then restart cpsrvd. These are the three steps in cPanel's advisory:

/scripts/upcp --force
/usr/local/cpanel/cpanel -V
/scripts/restartsrv_cpsrvd --hard

• Pinned or disabled updates. Point Update Preferences, or the CPANEL= line, at a tier that carries a patched build first.
• CentOS 7 or CloudLinux 7. The advisory says to set the version to 11.110 with whmapi1 set_tier tier=11.110, then run the steps.
• CentOS 6 or CloudLinux 6 on 110.0.50. Run sed -i "s/CPANEL=.*/CPANEL=cl6110/g" /etc/cpupdate.conf, then the steps, to reach 110.0.103.

One caution from the Update Preferences page: after you move to a new major version you cannot downgrade. In an emergency I stay on the same major version when it has a patched build, and plan the bigger upgrade separately.

What can I do if I cannot update yet?

cPanel's advisory gives two interim mitigations, and both lock your customers out of the panel as well. The first is to block inbound traffic on ports 2083, 2087, 2095 and 2096 at the firewall and to disable service subdomains, so the panels cannot be reached through names such as cpanel.example.com on ports 80 and 443:

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

The second is to stop cpsrvd and cpdavd entirely:

whmapi1 configureservice service=cpsrvd enabled=0 monitored=0 && whmapi1 configureservice service=cpdavd enabled=0 monitored=0 && /scripts/restartsrv_cpsrvd --stop && /scripts/restartsrv_cpdavd --stop

• Non-SSL ports. The list leaves out 2082 and 2086, which cPanel's firewall port list names as the cPanel and WHM ports without SSL. If they answer on your server, I block them too.
• WHMCS provisioning. WHMCS talks to the WHM API, normally on port 2087. Allow only the WHMCS server's IP address, or expect module commands to fail until you patch.
• Patch anyway. Rapid7 advises patching rather than relying on workarounds.

How do I check a cPanel server for signs of compromise?

Run the detection script from cPanel's advisory, then look for persistence it cannot see. Patching does not undo access an attacker already had, and cPanel's response post says every server that was unpatched at any point during the incident should be scanned with the current script.

Copy the script from the advisory, not a mirror, because cPanel revised it twice in May to remove false positives. Save it as ioc_checksessions_files.sh and run /bin/bash ./ioc_checksessions_files.sh as root. It reads /var/cpanel/sessions/raw and /usr/local/cpanel/logs/access_log. --verbose prints flagged sessions in full, and --purge deletes them after you confirm.

On a CRITICAL or WARNING result the script itself says to purge the affected sessions, force a password reset for root and every WHM user, audit /var/log/wtmp and the WHM access logs, and check for persistence such as cron jobs, SSH keys and backdoors. These are the checks I run for that last step:

last -F | head -30                          # logins recorded in /var/log/wtmp
awk -F: '$3 == 0 {print $1}' /etc/passwd    # only root should print
cat /root/.ssh/authorized_keys
crontab -l -u root; ls -la /etc/cron.d
whmapi1 api_token_list                      # WHM API tokens you did not create
find /home -name '*.sorry' 2>/dev/null | head

The last line is there because BleepingComputer reported on 2 May that attackers used the flaw to deploy "Sorry" ransomware, which adds a .sorry extension and leaves a README.md ransom note in each folder. A clean scan is not proof of a clean server, because someone with root access can edit logs.

What should I do if the server was compromised?

Rebuild instead of cleaning. The advisory says a root-compromised server needs its accounts moved to a known clean server, or the operating system reinstalled and the accounts restored from backups. This is the order I work in:

1. Snapshot the server and copy its logs to another machine before changing anything.
2. Restrict access at the provider's network firewall, not only on the server, which the attacker may control.
3. Build a clean, patched server and move or restore the accounts. Choose backups from before the first suspicious activity, which may mean before late February, and check them for .sorry files first.
4. Rotate every secret: root, WHM and reseller passwords, WHM API tokens, SSH keys and database passwords. If WHMCS provisions on this server, create a new token in WHM at Development > Manage API Tokens and enter it at Configuration > System Settings > Servers in WHMCS, scoped as in my WHMCS cPanel integration guide.
5. Tell affected customers as your contracts and local law require. I cannot give legal advice on that.

For the move itself, see how I approach server migration and backup.

What are the limits of this advisory?

• It is a summary. The version table reflects the advisory on 12 October 2026, and the advisory can still change.
• The script is narrow. It looks for the session artifacts of this exploit. It is not a malware scanner and will not find what an attacker installed afterwards.
• Mitigations have a cost. They cut your customers off. Treat them as hours, not weeks.
• Forced updates skip staging. On an exposed server I accept that. Take a quick snapshot if your provider offers one, but do not let a slow backup delay the patch.

For locking down WHM access after this, see my WHMCS firewall and server hardening guide, and if you want an outside pair of hands, I do this as server security hardening work.

Last reviewed 12 October 2026. Disclosure: I sell server security, WHMCS and web development work, so I am not neutral. I am CTO at ElySpace, a freelance developer for Marmaids LLC, and founder of WHMCSPilot and MagizAI. I have no tie to cPanel or WebPros.