Security Incident Report: cPanel CVE-2026-41940 Summary ------- WebHostingNZ recently responded to a serious security incident involving CVE-2026-41940, a cPanel & WHM authentication bypass vulnerability. This was a severe issue because successful exploitation could allow unauthorised access to cPanel/WHM sessions and, in the worst case, root-level compromise of a hosting server. cPanel’s own advisory describes the issue as an authentication bypass affecting cPanel software, including DNSOnly, on versions after 11.40. cPanel also provided a detection script for indicators of compromise and states that if a server is confirmed to be root-compromised, the server should be migrated to a known-clean server or the operating system should be reinstalled and accounts restored from backups. Because of the seriousness of the vulnerability, we did not simply patch the affected servers and continue running them. We treated the incident as a potential root-level compromise and took the safer approach: servers were shut down, rebuilt, and customer accounts were restored from backups onto clean systems. What happened ------------- The issue related to a cPanel zero-day vulnerability that was being actively exploited before the relevant security update had reached our servers through the normal cPanel update rollout process. Our servers had automatic security updates enabled. However, cPanel security updates are distributed through release tiers and rollout channels, and they do not necessarily reach every server globally at the same time. At the time the attack attempts occurred, the required patched versions had not yet been delivered to our affected servers through that normal update process. cPanel’s advisory for CVE-2026-41940 was published on 28 April 2026 US time, which was 29 April 2026 in New Zealand. The advisory was then updated multiple times as patched versions, mitigation steps, and detection guidance became available. Our servers had automatic security updates enabled, but the attack attempts against our environment occurred on 30 April 2026 NZ time, before the relevant update had reached our servers through cPanel’s normal staged rollout process. Immediate containment --------------------- As soon as we became aware of the attack activity, we acted within minutes. We took the proactive step of shutting down affected and potentially affected servers to prevent further access or continued exploitation. This caused disruption, but given the nature of the vulnerability and the potential for root-level access, leaving the servers online would have created an unacceptable risk. Attack attempts were seen across the environment. Not every server was successfully reached or impacted, but we treated the situation conservatively and assumed any exposed cPanel server could be at risk until proven otherwise. Why we rebuilt instead of only patching --------------------------------------- For many vulnerabilities, applying the vendor patch and restarting services is enough. This case was different. Because CVE-2026-41940 involved authentication bypass and could potentially lead to root-level compromise, we could not safely rely on patching alone after attack attempts had already occurred. A patched server may prevent further exploitation, but it does not automatically prove the server was clean before the patch was applied. That is why we chose the more disruptive but safer path: 1. Shut down exposed servers. 2. Build clean replacement systems. 3. Restore customer accounts from backups. 4. Apply available security updates and mitigations. 5. Manually repair services, databases, DNS, PHP settings, and application configuration where required. This approach aligns with cPanel’s later guidance, which states that where a server is confirmed to be root-compromised, administrators should migrate accounts to a known-clean server or reinstall the operating system and restore accounts from backups. Disclosure and reporting ------------------------ We disclosed/reported the incident to the Privacy Commissioner. This disclosure was made within 24 hours of becoming aware of the incident. At the time of disclosure, our position was that this was a serious security event involving attempted exploitation of a cPanel zero-day vulnerability. We had no evidence at that stage that customer data had been copied or exfiltrated, but because of the seriousness of the vulnerability, we treated the environment as potentially compromised and proceeded with full containment and rebuild work. Customer data ------------- At this stage, we have no evidence that customer data was accessed, copied, downloaded, or exfiltrated. We have reviewed available logs, access records, server state, and indicators of compromise. The evidence we found showed attack attempts and risk to server access, but we have not found evidence of customer files, databases, email contents, or other hosted data being downloaded or removed. We cannot say with absolute certainty that no data was viewed, because the vulnerability was serious and involved privileged access risk. However, based on the evidence available to us, we have not found evidence of customer data exfiltration. Impact to services ------------------ The main impact to customers was service disruption caused by containment, rebuild, and restoration work. Affected services included, depending on the account: - Website availability - cPanel access - DNS records - Database restoration - PHP version/module settings - WordPress and application configuration - Email account access - Stored email history in some cases Where websites and databases did not restore cleanly, we manually repaired them. Some databases required compatibility fixes due to MySQL-to-MariaDB differences before they could be imported successfully. Email accounts were restored where account configuration was available. However, historical email mailbox contents were not always recoverable from our backup system. Customers using Outlook, Apple Mail, Thunderbird, or similar may still have locally stored copies of older email on their own devices. Actions taken ------------- Our response included: 1. Immediate containment Servers were shut down within minutes of notification to stop further risk. 2. Environment isolation Exposed systems were treated as potentially compromised. 3. Clean rebuilds We rebuilt affected servers rather than continuing to run systems that may have been exposed to root-level compromise. 4. Security updates and mitigations Available cPanel patches and mitigations were applied once released and available to our servers. 5. Backup restoration Customer accounts were restored from available backups onto clean systems. 6. Log and indicator review We reviewed evidence of attack attempts and indicators of compromise. 7. Manual customer recovery work We repaired individual websites, databases, DNS zones, PHP modules, app configurations, and WordPress/SilverStripe/Node.js issues as they were identified. 8. Customer communication and support We worked through support tickets and requested customers report any remaining issues with specific domains, email addresses, or applications. Current position ---------------- At the time of this report: - Affected servers have been rebuilt or restored onto clean systems. - Available cPanel patches and mitigations have been applied. - We have not found evidence of customer data being taken. - Most services have been restored. - Remaining issues are being handled individually. - Customers are being asked to report any remaining problems with specific websites, email accounts, or control panel access. Lessons and follow-up actions -------------------------------- We are reviewing: - Zero-day monitoring and vendor advisory monitoring. - How quickly vendor security updates reach our servers through rollout channels. - Additional emergency mitigation steps before patches arrive. - Backup coverage and customer expectations around email storage. - Incident communication procedures. - Restore testing and per-account recovery processes. - Additional logging and alerting around cPanel/WHM access. We already had automatic security updates enabled. The key issue in this case was timing: the attack attempts occurred before the relevant cPanel update had reached our servers through the vendor rollout process.