cPanel emailed license holders on 7 September 2026 to pre-announce TSR-2026-09-08, a Targeted Security Release scheduled for 8 September 2026 that fixes a critical vulnerability in cPanel & WHM. The advance notice is the pattern cPanel uses for its most serious flaws: warn first, publish the technical detail and fixed builds when the patched packages are actually on the mirrors.
cPanel says it found the vulnerability internally through its own security review and is not aware of any exploitation in the wild. As with the domain-parking root RCE in August, "internally found" does not mean "safe to defer" — once the release notes are public, the diff is a roadmap for anyone building an exploit.
What cPanel has confirmed so far
- Severity: critical.
- Product: cPanel & WHM. The full affected version range ships with the release notes, not the pre-announcement.
- Delivery: servers on automatic daily updates get the patched build on their next cycle. Everyone else updates manually.
- End-of-life branches: servers on a version cPanel no longer supports will not receive the fix and must be upgraded to a supported branch (v134 LTS or later) first.
The pre-announcement did not include a CVE number, minimum patched builds, or an exploitation vector. Treat any of those circulating before cPanel's own advisory as unverified.
Identify affected servers now
You do not need the fixed build numbers to build your patch list — you need an inventory of what is running which branch. Sweep your fleet:
for h in $(cat servers.txt); do
printf '%s ' "$h"
ssh -n "root@$h" '/usr/local/cpanel/cpanel -V 2>/dev/null || echo unreachable'
done
Flag two groups: anything on an end-of-life branch that needs an upgrade before it can take the patch, and anything where automatic updates are disabled.
Check the update tier on a single server with:
grep -E 'CPANEL|updates=' /etc/cpupdate.conf
updates=manual or updates=never means that box will sit unpatched until you act.
Apply the fix on release day
Once cPanel confirms the patched builds, force the update rather than waiting up to 24 hours for the automatic window:
/usr/local/cpanel/scripts/upcp --force
Then confirm the running version and that the update actually completed:
/usr/local/cpanel/cpanel -V
grep -i 'fix\|abort\|error' /var/cpanel/updatelogs/update-$(date +%Y%m%d)*.log | tail
If upcp fails partway — a broken repo, a stale rpm.versions pin, a full /usr — work through fixing cPanel update failures in upcp before retrying. A half-applied update is worse than none.
End-of-life servers
If cpanel -V reports a branch cPanel no longer supports, the TSR packages will not reach it. You have to move it to a supported branch to get the fix:
echo 'CPANEL=lts' > /etc/cpupdate.conf
echo 'updates=daily' >> /etc/cpupdate.conf
/usr/local/cpanel/scripts/upcp --force
lts lands you on the current long-term-support branch (v134); use release instead if you want the newest supported line. Test on one server first — major-version jumps can surface EasyApache and MySQL/MariaDB compatibility issues that a same-branch patch never would.
After patching
Watch for cPanel's follow-up email and the public advisory with the confirmed CVE, the exact minimum builds, and the technical write-up. Diff that against your fleet inventory and close out anything still short of the fixed build. Keeping a current cPanel license is what entitles each server to these security packages in the first place — an expired or invalid license stops updates cold.