The numbers from the Sorry ransomware campaign against cPanel servers are stark: 44,000 compromised hosts, confirmed by Shadowserver, within 48 hours of the patch release for CVE-2026-41940. The vulnerability had a public proof-of-concept available on the same day the patch dropped. The attack began within hours.
Security teams operating on a “30-day patch cycle for criticals” framework — a common policy inherited from an earlier era of enterprise patching — cannot do anything useful with that 48-hour window. The policy says thirty days. The attacker said forty-eight hours.
The Window Has Already Closed for Most Organisations
The standard enterprise patch management posture for critical vulnerabilities — assess, test in staging, schedule maintenance window, deploy — was calibrated for a world where the window between public disclosure and mass exploitation was measured in weeks. That world no longer exists.
Coordinated disclosure norms mean that patches and public technical details now drop simultaneously. The time from “researcher submits to vendor” to “PoC on GitHub” is compressed to hours or days, because most CVE disclosures at the CVSS 9+ tier come with enough technical detail for a competent threat actor to write their own exploit within 24–72 hours. In cPanel’s case, the proof-of-concept was published on the same day as the patch. There was no grace period.
The 30-day remediation timeline that most vulnerability management programmes treat as aggressive was always optimistic for internet-facing infrastructure. For CVSS 9+ vulnerabilities with public PoC code, it is now a near-guarantee that you will be attacked before you remediate.
Why Patching Within 48 Hours Is Not Achievable at Scale — But Isolation Might Be
The rational response to this reality is not “patch faster.” Most enterprise security teams cannot realistically deploy an untested kernel or application patch to production infrastructure within 24 hours without incurring unacceptable operational risk — an outage from a bad patch can damage the business as severely as ransomware.
The rational response is to apply different logic to different exposure profiles. The cPanel case illustrates this clearly. cPanel’s management ports (2082, 2083, 2086, 2087) are frequently exposed to the internet because administrators access them remotely. That exposure is what made the mass exploitation possible — a CVSS 9.8 authentication bypass is dangerous, but it requires reachability to be exploited.
Internet-exposed management interfaces — web hosting control panels, monitoring dashboards, remote administration tools, server management UIs — represent a distinct risk tier that warrants a distinct response strategy. For these specifically, the correct posture is not “patch within 30 days” or even “patch within 7 days.” It is: restrict access to trusted IPs or VPN immediately upon a CVSS 9+ disclosure, independent of patch status. The patch can follow the normal controlled deployment cycle. The exposure reduction can happen today, by a firewall rule change that takes minutes and requires no testing.
What Prepared Organisations Did
The cPanel story has two populations of affected organisations: those that were compromised, and those that were not. The latter group did not necessarily patch in 48 hours. Most of them were protected by one of two conditions: cPanel auto-update was functioning and had already applied the patch, or their cPanel management interface was behind an IP allowlist or VPN that restricted who could reach it.
Auto-update is not glamorous security work. IP allowlisting is a basic network control. Neither requires a vulnerability management programme, a sophisticated patching tool, or a large security team. They require a decision — made in advance of the incident — that exposed management interfaces must be restricted, and that critical vendor auto-update mechanisms must be enabled and verified.
The organisations that were compromised made the opposite decision: they chose operational convenience (unrestricted remote admin access, manual patch scheduling) over a basic exposure reduction. That choice, multiplied across tens of thousands of servers, is why the Sorry ransomware group could conduct a profitable mass attack in 48 hours.
The Honest Conversation About Patch Policy
The security industry has long advised that vulnerability management programmes should define remediation SLAs by severity: 30 days for critical, 60 days for high, 90 days for medium. These timelines were always aspirational rather than data-driven — derived from what was achievable given enterprise change management processes, not from actual exploitation velocity.
The data from 2026 — cPanel in 48 hours, ConnectWise ScreenConnect within 5 days of a CVSS 10.0 patch, Citrix Bleed exploitation beginning 72 hours after disclosure — consistently shows that for externally-accessible infrastructure, 30-day SLAs mean you are managing vulnerabilities after they have already been exploited against you.
The conversation security teams need to have with their organisations is not “we need to patch faster.” It is “for internet-exposed infrastructure, we need a different framework: exposure reduction as an immediate response, patching as the completion of remediation, not the start of it.” cPanel in 48 hours is not an anomaly to be explained away. It is the operating tempo of modern ransomware operations. The remediation strategy has to reflect it.
Share this article