On 28 April 2026, we released security updates for cPanel & WHM to address CVE-2026-41940, an authentication vulnerability in the session management layer.
Once a verified and reproducible report was confirmed, our team made updates available within approximately 28 hours across all supported versions of the platform, as well as select legacy versions. As of today, over 98% of servers worldwide are running an updated version of cPanel & WHM. We continue to provide mitigation options for partners and customers who are unable to apply the update immediately. The complete update regarding patch coverage is listed in the following support article.
We take security extremely seriously and recognize the urgency this created. We remain focused on supporting our partners and customers.
What Was Addressed
CVE-2026-41940 is an authentication vulnerability in cPanel & WHM’s session management layer. Two separate code paths write to session files on disk: one path included an input-sanitisation step; a second path, invoked during Basic authentication handling, did not. The absence of that sanitisation step on the second path created a condition under which a specially crafted request could result in an unauthenticated session being treated as authenticated, granting access without valid credentials.
The vulnerability affects every version of cPanel & WHM after v11.40, and WP Squared up to v11.136.1.6. VulnCheck has assigned it a CVSS score of 9.8. CISA added it to the Known Exploited Vulnerabilities catalog on 1 May 2026. No other WebPros products are affected.
For servers on versions that cannot yet be updated, the support article provides mitigation guidance including cpsrvd service port blocking and ModSecurity rule application. We have also published a detection script that scans session files for the indicators of compromise associated with this attack. Note that, as of 1 May 2026, the script has been refined to remove an earlier false-positive on session.lock files.
How We Responded
The following sequence reflects how the response unfolded on confirming the vulnerability.
- 27 April, 10:47 CDT – Vulnerability confirmed and classified. Incident response initiated
- 28 April, 12:08 CDT – Support article (KB 40073787579671) published. Partner collaboration channels opened
- 28 April, 12:30 CDT – Code update merged into v138 and applied simultaneously across v136, v134, v126, v118, and v110
- 28 April, 16:19 CDT – Updated builds published across all supported tiers: LTS, STABLE, RELEASE, CURRENT, and EDGE. Approximately 28 hours from confirmation to general availability
- 29 April 15:18 CDT – Comprehensive email issued to all partners and direct customers, alongside publication of the indicators-of-compromise detection script. A second coordinated email followed on 1 May with expanded version coverage and additional mitigation measures
From there, the work continued in parallel: back-ports for legacy and end-of-life versions, automated remediation tooling, and direct support for partners working through specific fleet configurations.
Detection and Auto-Remediation Tooling
Two additional tools supported the broader response alongside the patches.
The indicators-of-compromise detection script, available at https://support.cpanel.net/hc/en-us/articles/40073787579671 scans session files for attributes associated with this specific exploit. It was refined on 1 May to correct a false-positive on session.lock files identified by partners during their own fleet testing. Any server that was unpatched at any point during the incident window should be scanned using the current version of the script.
Automated remediation tooling was deployed on our side to accelerate update adoption across the installed base, including a majority of affected builds, a number of end-of-life versions and a dedicated path for CL6/C6 environments accessible via run_security_update. This allowed us to drive patch coverage to over 98% of servers as of today without requiring manual intervention across every affected configuration. Coverage continues to expand through specific mitigation steps outlined in our support article.
Updates for Legacy Versions
In addition to all currently supported tiers, we delivered targeted updates for v86, v94, v102, v124, and v130, which have been outside standard support for some time, along with a dedicated update tier for CL6/C6 (CloudLinux 6) environments, available through the run_security_update autofixer.
Each of these required individual engineering work: targeted porting, version-specific validation, and full regression testing before release.
Working Closely with Partners on Edge Cases
The update coverage we can report today was built alongside our partners, not independently of them. Over the past week, hosting partners and server administrators have been active participants in the response, and we want to be specific about what that looked like.
Testing the Detection Script Against Live Fleets
Several partners ran the detection script across their server fleets in the days after publication and reported edge cases that had not surfaced in our own testing environment. This partner feedback is what produced the 1 May update to the script. Their environments effectively extended our validation coverage in ways that improved the quality of the tooling for everyone.
Validating Update Behaviour on Non-Standard Configurations
Pinned, locked, and version-restricted configurations do not always behave the way standard configurations do when an update runs. Partners with these environments worked directly alongside our engineering team to validate tooling behaviour against their specific setups, and to surface update blockers before broader rollout. Several of the back-ports for older version tiers were shaped directly by these conversations: partners described exactly what their fleet was running and why it could not move, and our team built the update path around that constraint.
Coordinating Customer Communications
A number of partners aligned their own customer communications with ours, requesting accuracy checks, version-specific guidance, and technical detail they could relay to their support teams. We supported each of these requests directly. The result was a more consistent message reaching downstream customers across a wide range of hosting environments.
Surfacing Partner-Specific Update Blockers
In several cases, partners identified conditions specific to their environment that prevented the standard update path from completing and brought them to our attention directly. Our team prioritised each one as part of the incident response rather than routing it through standard support. That prioritisation contributed directly to the pace at which update coverage moved.
“The server coverage we have reached within days of updates being available reflects a genuine collaboration. Partners tested our tooling, flagged issues, worked through non-standard configurations alongside our engineers, and shared information that made our response better. That kind of partnership is what this ecosystem is built on.”
Team cPanel
Further Context
During the course of April, we received separate reports regarding a possible pre-authentication issue in cPanel & WHM. For one of the two reports, our team engaged in follow-up correspondence with the person behind it to better understand, categorize and clarify the information provided. With the details available at that stage, we were unable to independently reproduce the reported behavior, and our initial assessment did not confirm a vulnerability. When the second report arrived with additional context, our team was able to reproduce and confirm the vulnerability the same day, and our incident response protocol began immediately.
What We Are Changing
The following commitments reflect our focus on continuous improvements in security practices, to address an evolving threat landscape.
| Commitment | What It Means |
| CVE Numbering Authority | We are applying to become a CVE Numbering Authority. This will give us the ability to assign CVE identifiers to vulnerabilities in cPanel & WHM directly, without reliance on third-party timelines. In the interim, we will continue issuing CVEs for any new items through an existing partnership with a CNA. |
| Partner & Customer Communication | We are formalising two distinct communication tracks. We will continue publishing a structured notice covering upcoming updates, priority items, and versions approaching end-of-life, giving our partners & customers the lead time needed to plan accordingly. For critical vulnerabilities, we will communicate directly ahead of public disclosure, if and where coordinated timing allows, as we have done in the past week. |
| Additional Capabilities | We are adding additional resources to our existing security tooling scans and review, driven by both humans and AI tooling. |
Thank You
Our customers, our partners and their customers, depend on this infrastructure, and that dependency carries a responsibility we take seriously. Our response has been to fix first, move quickly, provide clear and actionable communication, and commit to a continuous improvement in our processes to address a fast-changing threat landscape.
To the partners who worked alongside our team this past week, testing tooling, working through non-standard configurations, aligning customer communications, and flagging issues as they found them: the update coverage we have achieved is a direct result of that collaboration. Thank you.
To the security community whose scrutiny has kept this incident in clear focus: that scrutiny is appropriate and it produces better outcomes. Thank you.
The support article at https://support.cpanel.net/hc/en-us/articles/40073787579671 remains the live operational reference and is updated continuously.
