When things get a little rough out on the internet, the hosting.com team is already at work. The cPanel incident earlier this year was a real-world test of that.
Every day, hundreds of new flaws are found in software that the internet depends on. Some get responsibly disclosed. Others are discovered by attackers first and remain unknown for months. Either way, by the time a fix lands, exploitation is usually already underway.
What changed in 2025 is the timing. The gap between a vulnerability being disclosed and being exploited used to give defenders weeks, sometimes months. That window has collapsed. In many cases, it's now negative: attackers are inside before the patch is even published.
Here are the numbers
These come from the security reports we read internally: Mandiant’s M-Trends 2026, the Verizon DBIR, IBM’s breach cost data, and CISA’s running list of vulnerabilities already being used in the wild. You can see across all four aspects, the same picture starts to form.
Metric | The number | What it actually means |
Mean time to exploit, 2025 | −7 days | Attackers are, on average, in before the patch is published |
Mean time to exploit, 2018/19 | 63 days | Defenders used to have two months. Now they have none. |
Median time from initial access to handoff to a second threat group | 22 seconds | How fast attackers spread once they'reinside |
New entries in CISA’s KEV list in 2025 | 245 | Roughly one every 36 hours, all year |
Median time organizations actually take to patch | 32 days | The patch lands weeks after exploitation starts |
High-risk “edge” vulns that go unremediated | 1 in 3 | A permanent open door, left wide |
Global average data breach cost (IBM, 2025) | $4.44 million | What “we’ll get to it next week” costs |
Attackers move in a week before the patch ships, defenders take 32 days to apply it, and the average breach now costs $4.44 million. The window between disclosure and exploitation has closed.
Why 2025 broke the model
Three things changed at once, and each one made the others worse:
Automation got cheap. Mass-scanning the internet for a freshly disclosed vulnerability used to take real effort. Now it takes a credit card and an afternoon. The moment a CVE drops, someone is already scanning every IP they can reach for it.
AI lowered the skill floor. Attackers don't need to be expert exploit developers anymore. The hardest part of the attack chain, turning a disclosed flaw into working code, can be bought off the shelf or generated on demand. The talent gate is gone.
The economics tipped. Payouts are big, the path from flaw to payday is short, and more attackers are taking the trade. Reward up, effort down, supply follows.
So what does that mean if you're running a business on top of all this? The old answer is no longer enough. New attack windows open all the time. Keeping systems secure requires constant monitoring. That's where managed hosting comes in.
What managed hosting actually does
We get asked sometimes what the managed part of managed hosting actually involves. Fair question. On a managed Linux VPS with cPanel, our team handles OS patching, firewallmaintenance, security updates, backups, and round-the-clock monitoring without you raising a ticket. If we’re doing our job right, you don’t see most of it.
Our team watches security advisories the way air traffic control watches the sky. New CVEs, vendor warnings, threads in researcher Slacks, all of it gets picked up as it surfaces. Some of those signals are public. A lot comes from direct relationships we've built with software vendors over the years, which means we often hear about problems before they're public.
When something serious lands, three things happen at once:
Block first, ask later. If we can shut the front door on the attack without breaking your sites, we do, immediately. Ports, rules, access restrictions. These go in before a patch even exists.
Test the patch. Patches sometimes break things. We stage them, test against real configurations, and only push them once we know they hold.
Roll it out at scale. Thousands of customer environments, updated cleanly. This is the part most people underestimate.
And when something's happening, you hear from us. Plain English, with the parts that affect your site flagged up front. All of which sounds good, but here's what it looked like the last time we ran the playbook in earnest.
The cPanel incident
Earlier this year, a serious flaw in cPanel hit the wider hosting ecosystem. CVE-2026-41940, CVSS 9.8: a CRLF injection in cPanel & WHM session handling that let unauthenticated attackers forge a root WHM session. cPanel sits underneath more than 70 million domains globally, so the blast radius was, well, the internet.
The emergency Targeted Security Release landed on April 28, 2026. Active exploitation had already been traced back to late February, which meant attackers had a roughly two-monthhead start before public disclosure. At least 44,000 cPanel servers were compromised in the first wave. Public reports tied the activity to crypto mining, data theft, and a Go-based Linux encryptor branded “.sorry” deployed across compromised hosts. CISA added the CVE to its KEV list with a federal civilian patch deadline of May 3, 2026.
Our team’s response held to three things, in this order:
Within hours of the first credible reports, we restricted access at the network level on managed servers. Engineers were running mitigations before the public advisory was widely circulated. When a follow-up TSR landed ten days later covering three more flaws (CVE-2026-29201, 29202, and 29203), we did the same again.
We didn't wait for the official patch to ship. Mitigations went on first, blocking the routes attackers were already using. When the patch finally landed, we tested it against our own configurations (patches do break things, especially in their first hours), then rolled it out across managed servers as fast as we safely could.
Customers got told. Not in vague “we are aware of an ongoing situation” boilerplate. Actual information, plain English, with anything you needed to do (or not do) called out near the top.
For anyone running the same software on their own unmanaged box, the bad 'time period’ was the gap between finding out and fixing it. They had to spot the advisory, work out if it applied, pick a mitigation, test it, and ship it, usually mid-working-day. On our managed servers, that whole chain was already running before most of the public reports went out.
That’s how cPanel played out for our customers. The next one will be handled the same way.
Why this isn’t a one-off
Plenty of providers will declare an incident handled once the dust settles and go back to business as usual. We don’t, because the dust no longer ever settles. The next vulnerability is being written somewhere right now. So the question isn’t “did you handle that one?” It’s “have you built something that handles the next 50? And the 50 after that?”
Here’s what a properly managed hosting system looks like:
A team watching threats in real time, every day of the year, working from mitigation playbooks that don’t depend on a patch existing yet.
Direct lines to software vendors, so we’re often in motion before public disclosure.
Real people on the other end. Not scripts.
Where this leaves you
Honestly? If you’re already on a managed plan with us, not much. Carry on. When the next thing hits the news (and it will), you can carry on then too, because we’ll have been on it for hours already. Watching for these incidents is what we’re here for, so you don’t have to.
