Critical cPanel Security Update Expected September 8, 2026

The exact release time has not been announced

cPanel has confirmed September 8, 2026 as the expected release date for the security update, but the advance notification does not specify an exact release time. Administrators therefore cannot currently know whether the patch will become available in the morning, afternoon or evening in their local time zone.

cPanel says a follow-up notification will be sent as soon as the patch is live. That notification is expected to contain the exact patched versions, the affected version range and the technical remediation details.

Until those details are published, it would be premature to speculate about the attack vector or the precise vulnerable code path.

What is currently known about TSR-2026-09-08

The advance security notice describes the issue as a critical vulnerability affecting cPanel & WHM. cPanel says the vulnerability was identified internally through its security review process.

According to the notification, cPanel is not currently aware of exploitation of the vulnerability. The complete affected version range has not yet been published.

No CVE identifier, proof of concept, authentication requirement or detailed attack vector was included in the advance notice. Those details should only be assessed after the final advisory becomes public.

Hourly security updates are worth checking before the patch arrives

A cPanel server may be configured for normal daily updates while also checking for security releases independently every hour. This is controlled by the SECURITY_UPDATES value in /etc/cpupdate.conf.

cPanel's current documentation recommends the hourly setting so that security updates can be applied as soon as they are released rather than waiting for the normal nightly update cycle.

cat /etc/cpupdate.conf

CPANEL=release
RPMUP=daily
SECURITY_UPDATES=hourly
UPDATES=daily

/usr/local/cpanel/scripts/upcp --security

Verify the installed cPanel version and release tier

The locally installed version alone does not tell the whole story. Administrators should also verify whether a newer build is available on the configured release tier.

During our checks on September 7, both production systems were running cPanel & WHM 136.0.38 on the RELEASE tier. The WHM API reported 136.0.38 as both the current and newest RELEASE build at that moment, while 138.0.3 was available on the CURRENT tier.

That distinction matters because moving a production server to CURRENT simply because a newer major version exists is not the same decision as installing a security build published for the existing RELEASE branch.

/usr/local/cpanel/cpanel -V

/usr/local/cpanel/bin/whmapi1 --output=jsonpretty get_update_availability

/usr/local/cpanel/bin/whmapi1 --output=jsonpretty get_available_tiers

End-of-life versions require special attention

The advance notice explicitly tells administrators to identify systems running end-of-life versions because unsupported releases may need to be upgraded before they can receive the fix.

cPanel's release documentation currently lists version 136 with an approximate August 2026 end-of-life date and version 138 with an approximate November 2026 end-of-life date. The same documentation also states that a previous version does not become EOL until the upcoming version reaches the RELEASE tier.

For that reason, the definitive information for this incident will be the supported and minimum patched builds published with TSR-2026-09-08 rather than assumptions based only on an approximate lifecycle date.

A security update is useful only if the package manager can install it

Preparing for a critical cPanel patch should include more than checking the cPanel version. Available disk space, package-manager health and previous update logs can all determine whether an update completes successfully.

Our pre-release checks included the staging filesystem, inode availability, the latest cPanel update log and the RPM dependency state.

df -h /usr /var /home /tmp

df -i /usr /var /home /tmp

yum check

tail -100 /var/cpanel/updatelogs/last

We found obsolete kmod-lve packages during the preparation

The most useful finding from our preparation had nothing to do with the still-undisclosed cPanel vulnerability itself. On two CloudLinux 8 production servers we found older kmod-lve packages installed alongside the current LVE module package.

On one production system, the package database contained versions 2.0-49, 2.0-50 and 2.1-61.1 simultaneously. On a second production system, versions 2.0-43, 2.0-44 and 2.1-61.1 were present.

The active kernel module on both systems was already the newer 2.1-61.1 generation, meaning that the older RPM packages were redundant leftovers rather than the module currently providing LVE functionality.

rpm -qa | grep '^kmod-lve' | sort

kmod-lve-2.0-49.el8.x86_64
kmod-lve-2.0-50.el8.x86_64
kmod-lve-2.1-61.1.el8.x86_64

One earlier update had already exposed the dependency problem

The obsolete packages were not merely cosmetic. A previous cPanel package update on one of the systems had already failed during the operating-system package phase.

The error involved the older kmod-lve package requiring a kernel symbol provider that the package transaction could not satisfy.

This is exactly the kind of latent update problem that should be discovered before a critical security release becomes available rather than while administrators are attempting to deploy the patch.

Problem: package kmod-lve-1:2.0-49.el8.x86_64 from @System requires kernel(oops_in_progress) = 0x299b2b01, but none of the providers can be installed

Preview destructive package operations before executing them

We did not immediately remove the obsolete packages. The first step was a DNF transaction preview using --assumeno.

The preview confirmed that only the two obsolete kmod-lve packages would be removed and that no unrelated dependencies would disappear with them.

Only after verifying the transaction did we execute the actual removal.

dnf remove --assumeno \
  kmod-lve-2.0-49.el8.x86_64 \
  kmod-lve-2.0-50.el8.x86_64

DNF appeared to pause while weak-modules and dracut were working

During the kmod-lve cleanup, DNF remained on the RPM scriptlet stage for several minutes. From the original SSH session it could easily have looked as if the transaction had frozen.

A second SSH session showed that the operation was still active. The RPM scriptlet had started weak-modules, which in turn was running dracut and later depmod while processing the installed kernels.

This was an important operational observation: interrupting an RPM transaction with Ctrl-C or kill -9 simply because no new terminal output appears for several minutes could cause a significantly worse problem.

dnf
 └─ rpm scriptlet
     └─ weak-modules --remove-modules
         └─ dracut

weak-modules
 ├─ depmod
 └─ grep

The obsolete packages were removed without rebooting the server

After the kernel-module maintenance scripts completed, the DNF transaction finished normally and only kmod-lve 2.1-61.1 remained installed on the system.

The loaded kmodlve module remained active and yum check returned without dependency errors after the cleanup.

We deliberately did not combine this preparation with an unplanned kernel reboot. The objective was to remove an update blocker before the cPanel security release, not introduce additional maintenance risk immediately before it.

rpm -qa | grep '^kmod-lve' | sort

lsmod | grep kmodlve

modinfo kmodlve | grep -E 'filename|version|vermagic'

yum check

KernelCare reduced the need for an immediate kernel reboot

Both inspected CloudLinux systems were running KernelCare. As a result, the physically booted kernel and the effective live-patched kernel level were different.

On one system, the booted kernel was older than the effective live-patched kernel level reported by KernelCare.

That allowed us to keep the planned kernel upgrade and reboot for a dedicated maintenance window while still cleaning up the obsolete LVE packages before the cPanel security release.

uname -r

kcarectl --uname

What we will verify when TSR-2026-09-08 is released

The final advisory will determine the actual remediation work. Once cPanel publishes TSR-2026-09-08, the first task is to compare the installed build with the minimum patched build for the relevant supported branch.

The vulnerability should then be assessed using the published technical details rather than assumptions made before disclosure.

• the CVE identifier, if one is assigned
• the complete affected cPanel & WHM version range
• minimum patched build numbers
• the attack vector and whether authentication is required
• the impact of successful exploitation
• whether active exploitation has been observed
• whether manual remediation is required
• whether cPanel publishes indicators of compromise or detection guidance
• whether the automatic security update has already installed the fixed build

Preparation turns a critical release into a verification task

The most valuable part of an advance security notification is the time it gives administrators to verify the update path before the actual vulnerability details become public.

A server may have automatic security updates enabled and still fail to install a patch because of disk-space problems, package conflicts, obsolete kernel modules or a previous incomplete update.

By checking those conditions in advance, the work after release becomes much simpler: identify the fixed build, confirm that the server has received it and investigate only if the expected update did not complete.

When TSR-2026-09-08 becomes public, we will publish a separate technical follow-up with the confirmed vulnerability details and patched version numbers.

Official cPanel documentation

• cPanel & WHM Update Configuration File – cpupdate.conf
• cPanel Product Versions and the Release Process
• cPanel TSR announcements, disclosures and security updates

Related 1B Telecom technical articles

• AH00288 on cPanel: why the Apache scoreboard fills up after graceful restarts
• CPANEL-53195: external requests trigger HTTP 500 via the cPanel 404 safelock path