# cPanel CVE Build Numbers 2026: Is Your Server Safe? Source: https://srvscripts.com/guides/cpanel-cve-build-numbers-2026/ Updated: 2026-10-03 Publisher: srvScripts (https://srvscripts.com/) Between late April and late September 2026 cPanel shipped a security release roughly every two to three weeks, and most of them fixed a path to root. Auto-updates handle this quietly on most servers, but “most” is not “all”: servers with updates disabled, servers on Rocky Linux stuck at 133, servers where `upcp` has been failing silently, and servers on the 110 tier that someone forgot about are all still exposed. This guide gives you the build numbers to check against and the commands to check them with. In short: Read the full version with cat /usr/local/cpanel/version and compare the build against the September 2026 minimums: 138.0.8, 136.0.41, 134.0.57 or 110.0.143. **Short answer:** Read the full version with `cat /usr/local/cpanel/version` and compare the build against the September 2026 minimums: 138.0.8, 136.0.41, 134.0.57 or 110.0.143. Anything at or above those on its tier includes every fix from CVE-2026-41940 through CVE-2026-87899; anything lower, on a retired tier such as 132, or stuck at 133 on Rocky Linux is exposed and needs `upcp`, a tier change or an OS migration. ## Get the exact build The version string has four parts, for example `11.138.0.8`. The `138` is the major version, `0` is the minor and `8` is the build. Fixes are described per major version and build, so you need all of it: ``` whmapi1 version cat /usr/local/cpanel/version ``` Across a fleet, pull it from every server in one pass over SSH or through the WHM API with a token, and write the result somewhere you can compare against next week. ## The 2026 timeline and fixed builds Treat the builds below as the minimum. Anything equal or later on the same major version includes the fix; anything earlier does not. - **CVE-2026-41940** (28 April, CVSS 9.8). CRLF injection in the Basic Auth handling of cpsrvd allowed unauthenticated root on WHM and bypassed 2FA. It was exploited as a zero-day, used to deploy the `.sorry` ransomware, and is on the CISA KEV list. Fixed in emergency builds of 132, 134 and 136 the same day. If a server was internet-facing on 2087 before it was patched, assume compromise and follow the [incident response guide](/guides/cpanel-root-escalation-incident-response/). - **CVE-2026-29201, 29202, 29203** (8 May). Fixed in 136.0.9, 134.0.25, 132.0.31 and 110.0.117. - **Exim CVE-2026-40684 to 40687** (June). Exim 4.99.2 bundled in 136.0.7 and 134.0.23. On a server that has moved to 138, Exim is 4.100.1 and already past this. - **LiteSpeed cPanel plugin CVE-2026-48172 and 54420** (June). Not a cPanel build; the plugin must be 2.4.8 or later. Check with `rpm -q lsws-whm-plugin` or `cat /usr/local/cpanel/whostmgr/docroot/cgi/lsws/VERSION`. - **CVE-2026-58048** (4 August, CVSS 9.4). SQL execution as the database root through the database rename path, shipped with CVE-2026-58047 (cpsrvd request smuggling) and an Exim `.forward` privilege escalation. Fixed in 136.0.32, 134.0.48 and 110.0.137. - **CVE-2026-65643** (27 August). Parked or addon domain creation leading to root. Fixed in 138.0.2, 136.0.37, 134.0.53 and 110.0.141. - **CVE-2026-67401** (8 September). SQL injection in EmailTrack leading to root. Fixed in 138.0.4, 136.0.39, 134.0.55 and 110.0.143. - **CVE-2026-87899** (22 September). Any cPanel account to root. Shipped alongside CVE-2026-68490 (CalDAV cross-account access) and CVE-2026-87900 (WP Toolkit cross-account, fixed in WP Toolkit 6.11.3). Fixed in 138.0.8, 136.0.41, 134.0.57 and 110.0.143; the 110 build number is the same as for the previous bulletin, so on that tier confirm against the advisory text rather than the number alone. As of the last week of September 2026 the current builds are around 138.0.10 and 136.0.44. A server on either of those, or on 134.0.57 or later, is past everything listed. Check the changelog for your build if you need the precise minor for a fix, because emergency builds occasionally shipped in more than one increment. ## A script to check a server Save this as a quick check and run it on each server. It compares the running build with the September minimums: ``` #!/bin/bash v=$(cat /usr/local/cpanel/version) major=$(echo "$v" | cut -d. -f2) build=$(echo "$v" | cut -d. -f4) case "$major" in 138) min=8 ;; 136) min=41 ;; 134) min=57 ;; 110) min=143 ;; *) echo "$v: unsupported major $major, no security fixes available"; exit 2 ;; esac if [ "$build" -ge "$min" ]; then echo "$v: OK (>= $major.0.$min)"; else echo "$v: BEHIND, need $major.0.$min"; exit 1; fi ``` The exit code makes it easy to feed into monitoring. Our [server security audit script](/scripts/server-security-audit/) includes this check along with the CSF, kernel and WP Toolkit version tests. ## When a server is behind First find out why. `tail /var/cpanel/updatelogs/last` will show one of three things: updates are set to manual or never, `upcp` is failing, or the OS is no longer supported by the tier. Each has a different fix: - Updates off: `whmapi1 set_cpanel_updates updates=daily` and then `/scripts/upcp --force`. - Failing: see [fixing upcp failures](/guides/cpanel-upcp-failed-upgrade-blocked/). - Unsupported OS: a Rocky Linux server is stuck at 133 and cannot receive any of the fixes from May onwards. That server is unpatchable in place and needs the [AlmaLinux migration](/guides/rocky-linux-cpanel-to-almalinux/) as an emergency task, or the accounts moved elsewhere. A 110-tier server on CentOS 7 still gets fixes until December 2026 and then does not. A common pitfall is a server on 132. That tier is not listed in the September builds because it is retired; the emergency builds in April and May were its last. Move it to 134 with `whmapi1 set_tier tier=134` and run `upcp`. ## Verify beyond the version number The version string proves the code is present. It does not prove the server was not compromised while vulnerable. After bringing any server up to date, spend ten minutes on: ``` grep -rl 'sorry' /home/*/public_html --include='*.txt' -l 2>/dev/null | head whmapi1 api_token_list last -a | head -30 find / -xdev -newer /usr/local/cpanel/version -perm -4000 -type f 2>/dev/null ``` Unexpected API tokens, root logins from unknown addresses, and new setuid binaries are the usual indicators. If any turn up, the [incident response guide](/guides/cpanel-root-escalation-incident-response/) is the next step. Otherwise, add the build check to a weekly job and move on; the pattern since April suggests the next bulletin is never far away. ## CPanel CVE build numbers at a glance **Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/). **Related guides:** [Connecting an AI agent to a cPanel account with MCP (v138) and auditing what it can do](https://srvscripts.com/guides/cpanel-mcp-ai-agent-access-138/) · [Fix Imunify360 missing from the WHM interface (enable-plugin and other causes)](https://srvscripts.com/guides/fix-imunify360-missing-from-whm/) · [Locking down WHM: 2FA, cPHulk, Host Access Control and scoped API tokens](https://srvscripts.com/guides/lock-down-whm-2fa-cphulk-api-tokens/). ## Frequently asked questions ### Does a server on cPanel 132 receive the 2026 security fixes? Only the April and May emergency builds. The 132 tier was retired before the August and September bulletins, so a 132 server must move to 134 with `whmapi1 set_tier tier=134` and run upcp to get the CVE-2026-58048 and later fixes. ### How long does upcp take to bring a server to a patched build? A forced `/scripts/upcp --force` usually finishes in ten to thirty minutes depending on how far behind the server is, and the security builds do not require a reboot unless a kernel update ships alongside. ### Can I confirm the CVE-2026-41940 fix without checking the build number? Not reliably. The version string is the authoritative signal, but also check for compromise indicators such as unknown API tokens, unexpected root logins and new setuid binaries, because the flaw was exploited before many servers were patched.