Web Hosting Had a Rough Week.
The past few weeks have shown web hosting providers that security incidents can strike suddenly, spread quickly, and force difficult decisions before anyone has a complete picture. Between the cPanel vulnerability, emergency port restrictions, infrastructure compromises, DNS recovery, the Linux Copy Fail issue, and the newly disclosed DirtyFrag vulnerability, hosting companies were pushed to rethink their standard security routines.
The question was no longer simply, “Are we secure?”
The better question became, “What happens when prevention is not enough?”
Security tools matter.
Firewalls matter.
Bot protection matters.
Malware scanning matters.
Patch management matters.
Two-factor authentication matters.
But when systems are exposed, compromised, taken offline, or forced into emergency lockdown, the final safety net remains the same as it has always been.
A clean, reliable, recent, and restorable backup.
For the web hosting industry, this was not just about one vulnerability or one platform. It was a broader warning about how quickly trust in infrastructure can be shaken when authentication systems, control panels, DNS infrastructure, Linux kernels, shared hosting environments, and server-level access become part of the threat surface. It was also a powerful reminder that disaster recovery and backup solutions should be treated as core infrastructure, not optional add-ons.
The cPanel Vulnerability Put Hosting Providers on High Alert
The cPanel issue was not just another routine security advisory. It involved a serious authentication and privilege escalation concern affecting cPanel and WHM environments, with successful exploits reported in the wild. That changed the conversation immediately for hosting providers. This was not a theoretical risk that could be scheduled for future maintenance. It was an active security event that required quick decisions, customer communication, and immediate reduction of exposure.
What made the situation more concerning was the reported timeline. According to reports shared within the hosting community, malicious exploitation attempts may have been observed as early as February 23, 2026, nearly two months before the public emergency patch was released on April 28, 2026. If accurate, that means some hosting environments may have been exposed for an extended period before the broader industry had clear public guidance or a confirmed fix.
Security issues can happen to any software company, especially one operating at the scale and complexity of cPanel. But when a vulnerability can allow authentication bypass and administrative access, the speed, transparency, and clarity of the response matter just as much as the patch itself.
The emergency security updates released on April 28, 2026, were critical, and hosting providers moved quickly to apply them. Patched versions included builds such as 11.86.0.41 and 11.110.0.97, among others, depending on the supported version branch. But the industry’s concerns about delayed response should not be ignored. Reports of active exploitation before the public patch, combined with the number of potentially compromised servers, show why hosting providers need more than vendor trust. They need layered defenses, independent monitoring, tested recovery plans, and clean backups.
The cPanel Risk Is Still Evolving
The cPanel story also did not end with the April 28 emergency patch. On May 8, 2026, cPanel issued an advanced notice to hosting operators that three additional vulnerabilities in cPanel and WHM were being patched at 12:00 p.m. EST. The CVE identifiers are CVE-2026-29201, CVE-2026-29202, and CVE-2026-29203. Unlike the previous authentication bypass incident, cPanel withheld full technical details until the patch was available, stating that the details would be published at the same time as the release. cPanel’s release notes later described the fixes as an arbitrary file read in the LOADFEATUREFILE adminbin call, a Perl code injection vulnerability in the create_user API call, and an unsafe symlink-handling issue that could allow a user to chmod an arbitrary file, enabling denial-of-service and possible privilege escalation.
This is the second cPanel security event in ten days, and the contrast matters. CVE-2026-41940, the April 28 authentication bypass, carried a CVSS score of 9.8 and was reported as actively exploited before the public patch was available. The May 8 approach appears different. This time, hosting operators received advance notice before the patch dropped, with technical details deliberately withheld until the fix was in place. That is a better disclosure posture for providers who need time to prepare without giving attackers a technical roadmap before patches are available. But it also reinforces the larger point: cPanel remains a critical part of the hosting stack, and when multiple security events land in such a short window, providers need to treat control panel risk as an ongoing operational concern, not a one-time patch event.
How Hosting Providers Responded to the cPanel Issue
“At Rocket.net and Hosting.com, we remain vigilant when it comes to security, especially in the new era we’re living in with AI. From direct vendor relations to security distros, we have been aware of every exploit notice in minutes. For some of the more critical ones, such as the cPanel exploit, we were able to immediately close off the cPanel ports, protecting the entire fleet since we manage our own stack top to bottom.”
Ben Gabler (Hosting.com / Rocket.net)
KnownHost moved quickly and publicly announced that they were blocking WHM and cPanel login ports across their network, including 2082, 2083, 2086, and 2087, while cPanel investigated the issue and prepared patches. That kind of decision is never convenient. Customers rely on control panel access for normal administration, but when login access itself becomes a potential point of compromise, reducing exposure becomes the priority.
InMotion Hosting took a similar protective approach. Their team temporarily closed the ports used for cPanel and WHM access on affected servers. Those ports remained closed until cPanel released patches, the InMotion Hosting team applied them, and the fix was validated. Their communication made an important distinction for customers. Websites, applications, databases, and email continued to operate normally, but direct cPanel and WHM logins could be temporarily unavailable while the issue was being contained.
Bluehost also restricted inbound access to cPanel, WHM, Webmail, and WebDisk ports on affected VPS and Dedicated servers running cPanel. This included cPanel ports 2082 and 2083, WHM ports 2086 and 2087, Webmail ports 2095 and 2096, and WebDisk ports 2077 and 2078. Customers were advised not to disable firewall rules, to update cPanel, to audit recent activity, to review login history, to move away from CentOS 6, and to take fresh backups of sites, databases, and email accounts.
Why Fresh Backups Matter During a Security Incident
When a security event hits, most of the conversation naturally focuses on the exploit, the patch, the firewall rule, the malware signature, the bot traffic, the exposed port, or the affected version. That is understandable. The first job is to contain the immediate risk. But once the immediate danger is reduced, the conversation shifts to recovery.
What was changed?
What was accessed?
What was deleted?
What DNS data was lost?
What accounts were touched?
What files can still be trusted?
What configurations were altered?
What customer environments are safe to keep running?
What needs to be restored from a known-good point?
That is where backups move from being a checkbox to being part of business continuity.
A backup is valuable when it is recent, protected, complete, accessible, and easily restorable. During an incident, a reliable backup allows businesses to recover lost files, restore critical data, and minimize downtime. The ability to return to a stable, known-good state can prevent prolonged disruption and protect customer trust.
The Big Wet Fish Example: DNS Backups Made the Difference
Stephen Kinkaid of Big Wet Fish shared one of the clearest real-world examples. His team dealt with compromised servers and a broader impact on DNS infrastructure, but the company recovered because it had reliable backups of its DNS zone files. In his words, having reliable backups of their DNS zone files made all the difference.
That example is important because it expands the backup conversation beyond website files and databases. Backups protect more than WordPress installs, MySQL databases, and account-level files. They can also protect DNS zones, email data, account metadata, server configuration, control panel data, SSL details, and operational records. These safeguards make restoration more reliable during an incident.
If DNS goes down, websites may still exist, but customers cannot reach them. If account data is damaged, files alone may not be enough. If email data is lost, business continuity is affected. If the server configuration is compromised, recovery becomes slower and riskier. If backups are incomplete, support teams are forced to rebuild from memory, logs, assumptions, and customer pressure.
The lesson from Big Wet Fish was not that everything went perfectly. The lesson was that reliable backups turned a serious infrastructure incident into a recoverable event.
Copy Fail Added Another Layer of Linux Risk
While the industry was still focused on the cPanel vulnerability, Linux Copy Fail added another layer of concern for infrastructure teams. Copy Fail, tracked as CVE-2026-31431, was described as a Linux kernel privilege escalation flaw affecting major distributions. For hosting providers, the concern was not just the vulnerability itself. It was what the vulnerability represented.
Modern hosting environments depend on layers of isolation. Customers, websites, containers, processes, databases, and services are all expected to operate within defined boundaries. A privilege escalation vulnerability threatens those boundaries by allowing an attacker who already has some level of access to gain more control than they should have.
Ben Gabler explained,
“We have robust fleet management on every node that also allows us to roll patches out instantly, protecting from things such as Copy Fail. At the end of the day, our managed customers pay us to keep them safe and online, and we have teams working 24/7/365 to do that as best as possible.”
That matters in hosting because local access is not always unusual. Shared hosting customers may have shell access. Web applications can be compromised. Scripts can run under customer accounts. Containers and workloads may exist in multi-tenant environments. When a local privilege escalation vulnerability appears, the question becomes whether a limited foothold can turn into broader control.
Copy Fail was a reminder that hosting security is not only about blocking remote attacks at the edge. It is also about what happens after an attacker gains access to a customer account, a process, a container, or a limited user environment.
DirtyFrag Raises the Stakes for Shared Hosting and Linux Servers
Then DirtyFrag entered the conversation, raising the stakes even further.
DirtyFrag is a local privilege escalation vulnerability in the Linux kernel that can allow a local unprivileged user to gain root privileges. It is especially relevant to web hosting because it challenges one of the foundational assumptions of shared-server security: that one user account should not be able to break out and take over the entire machine.
“This week has been a real stress test for everyone in hosting, and I think it’s a useful one. Four security events in eleven days: the cPanel auth bypass, Copy Fail, today’s cPanel CVE batch, and now Dirty Frag. For our customers, the practical reality is: the auth bypass was contained the same evening it was disclosed and remediated as soon as cPanel released the fix; Copy Fail was hotpatched on 30 April, before any official kernel was available; and Dirty Frag is mitigated now with patched kernels staged for rollout the moment they’re ready. What makes that possible isn’t heroics; it’s a curated RSS reader that gives us an early signal and a mature Ansible automation layer that lets us act on it in minutes. We’re expecting a lot more patches in the coming months, and we have been preparing ourselves for it.”
Tom Mazer (Hosted.com)
AlmaLinux also moved quickly to respond. In its May 7 advisory, AlmaLinux stated that DirtyFrag affects all supported AlmaLinux releases and confirmed that the issue chains two distinct kernel bugs, now tracked as CVE-2026-43284 for the IPsec ESP path and CVE-2026-43500 for the rxrpc path. AlmaLinux said patched kernels were already available in its testing repository and that it chose to ship those builds ahead of a Red Hat update due to the severity of the flaw and its ease of exploitation. AlmaLinux also provided temporary mitigation guidance for administrators who cannot reboot immediately, including blacklisting the affected esp4, esp6, and rxrpc modules, while warning that systems using IPsec ESP or AFS/rxrpc should proceed with caution, as those workloads may break.
DirtyFrag is not described as a direct remote exploit that allows anyone on the internet to instantly take over a server from the outside. It requires local code execution. But in the hosting world, local code execution is not rare. Shared hosting customers, reseller accounts, SSH users, compromised web applications, vulnerable plugins, and poorly isolated workloads can all serve as paths to code execution on a server.
On a shared hosting server, the entire model depends on account isolation. One user should not be able to read another user’s files. One website should not be able to access another website’s database credentials. One compromised account should not result in a full server compromise. DirtyFrag attacks that assumption. If a limited user can become root, then the separation between accounts becomes far less meaningful.
The practical impact is serious. Root access means an attacker can read files, access databases, modify configuration, install backdoors, create users, delete data, intercept sensitive information, and potentially compromise every account on the server. For hosting providers, that turns a single local foothold into a full infrastructure incident.
Why DirtyFrag Is Different From Copy Fail
DirtyFrag matters because it arrived immediately after Copy Fail, but it should not be treated as the same issue. Copy Fail had already forced hosting providers to review Linux kernel exposure and consider mitigations. DirtyFrag widened the concern by showing that the broader class of kernel-level privilege-escalation risks was not addressed.
That timing matters. Infrastructure teams were already patching, mitigating, and reviewing systems. Then DirtyFrag appeared with public exploit details while many defenders were still working through the previous round of kernel risk.
The key concern is that mitigating one vulnerability does not automatically address the next. DirtyFrag uses different code paths than Copy Fail, so providers cannot assume earlier mitigation fully protects them from the newer issue. This is exactly the kind of detail that should make every infrastructure team pause. Applying a single mitigation for a single vulnerability does not mean the broader class of risk is resolved.
DirtyFrag also created a difficult disclosure scenario. A public exploit existed while patch availability was still catching up across distributions. That leaves hosting providers in a difficult position. They need to mitigate risk quickly, communicate clearly, and decide how to handle systems where normal patching is not yet available or where mitigations could affect services such as IPsec VPN functionality.
DirtyFrag Shows Why Root-Level Recovery Planning Matters
DirtyFrag is also a reminder that root-level compromise is not just another security alert. It changes the entire recovery model.
If a normal website account is compromised, the recovery path may involve cleaning files, resetting passwords, restoring a website, patching plugins, and reviewing logs. That is serious, but it is usually contained. If the root is compromised, containment becomes much harder. The attacker may have modified binaries, added hidden users, changed system configuration, tampered with logs, accessed customer data, altered backup paths, or installed persistent backdoors.
At that point, the question is no longer simply, “Can we clean the infected website?”
The question becomes, “Can we trust this server?”
That is why DirtyFrag belongs in the same conversation as the cPanel issue and Copy Fail. These are not just software bugs. They are trust events. They force hosting providers to think about what happens when a server’s integrity is in doubt. They also reinforce the need for disaster recovery to include clean restore points, off-site backup destinations, account-level recovery, server rebuild procedures, and tested restore workflows.
Not Every Incident Was a Server Takeover
Not every security event involved a server takeover. Some targeted availability itself. Canonical’s Ubuntu infrastructure also faced a sustained DDoS attack, disrupting access to key services and reminding hosting providers that even trusted upstream infrastructure can become part of the operational risk chain. For hosts, that means resilience is not only about protecting your own servers. It is also about preparing for the failure or disruption of the platforms, vendors, distributions, and services your infrastructure depends on.
And then, Let’s Encrypt Joined the Game
As if the week had not already been chaotic enough, Let’s Encrypt also paused certificate issuance after being made aware of a “potential incident.” At the time of writing, the organization had not confirmed whether this was a compromise, a compliance issue, or another operational security concern.
But the response itself matters. When a trusted part of the web infrastructure pauses issuance, it shows how fragile the chain can feel when authentication, certificates, control panels, Linux kernels, and recovery systems are all under pressure in the same week.
Security and Backup Cannot Be Separate Conversations.
This week also showed why security and backups should not be treated as separate conversations. Security teams work to prevent, detect, block, and contain threats. Backup and disaster recovery systems enable recovery when prevention and containment are not enough. A mature hosting company needs both.
Speaking with Aaron Campbell from Monarx, the message was clear. Their phone has been ringing, and security teams can help detect, block, and respond to threats. They can even help with post-compromise forensics and cleaning data to make it safe to restore. Cleaning a compromised environment can work in some cases, and many hosts are putting serious effort into that path. But when a full root compromise occurs, the best and safest path is a robust backup and disaster recovery plan.
Security can reduce risk. Security can stop known threats. Security can buy time. Security can help identify what happened and what needs to be cleaned. But when systems are fully root-compromised, backups are often the cleanest way back for hosting providers.
That is the reality the hosting industry has to sit with.
Root-Level Compromise Changes the Entire Risk Model
Everyone is worried about bots, malware, zero-days, exposed ports, vulnerable plugins, compromised credentials, and privilege escalation. They should be. But a root-level compromise changes the entire risk model because the attacker may no longer be operating within a single application, account, plugin, or isolated service.
When root access is compromised, the entire environment must be treated with caution.
That also means many partners and integrations are at risk during a root-level attack. In a cPanel environment, this can include critical tools such as JetBackup and other software that depend on the server’s security and integrity. When an attacker gains root access, the risk is no longer limited to a single application or a single exposed login. The entire server, its integrations, connected services, and recovery path must be carefully reviewed.
This is why backup software itself must be treated as critical infrastructure. It is part of the recovery strategy, but it also exists inside the broader security environment. Hosting providers need to protect access to backup systems, enforce strong authentication, limit unnecessary exposure, monitor activity, and ensure backup destinations are protected from the same compromise affecting production servers.
How JetBackup Takes These Threats Seriously
At JetBackup, we take these threats seriously because we understand how central backup and disaster recovery are to hosting providers, partners, and end users. When incidents like this happen, backups are not theoretical. They become the difference between panic and process, between extended downtime and structured recovery, between guessing and restoring from a known-good state.
JetBackup currently uses two-factor authentication to help defend against bad actors and unauthorized access, and we are continuously working to reduce risk across our products, integrations, and partner environments. Security is never finished. It requires constant review, faster response, stronger defaults, and a clear understanding that backup software must be protected as part of the larger hosting infrastructure.
The goal is not only to help providers restore data. The goal is to help providers build safer, more reliable recovery workflows that hold up under real pressure. That includes thinking about how backups are created, where they are stored, who can access them, how restores are performed, and how quickly a provider can recover when something goes wrong.
The Questions Every Hosting Company Should Be Asking
This should push every host to ask harder questions about backup, security, and disaster recovery.
Do we have recent backups of customer websites, databases, DNS zones, email, and server configuration?
Are those backups stored offsite and protected from the same compromise affecting production?
Can customers self-restore without waiting for a support ticket?
Can our team restore a full account, a single database, a DNS zone, or an entire server under pressure?
Have we tested restores recently, or are we simply hoping the backup job completed successfully?
Do we have a disaster recovery process that turns hours into minutes?
Hosting companies also need to ask whether they know what to do after a root-level compromise.
Can the server be trusted?
Should the environment be rebuilt?
Do we have a known-good restore point?
Are backups isolated from production credentials?
Are backup destinations protected from the same attacker?
Can we restore data without restoring malware, backdoors, or compromised configurations?
These questions are not only technical. They are business questions. They affect customer trust, support workload, brand reputation, uptime, revenue protection, and the ability to communicate confidently during an incident.
A hosting provider with strong security but weak recovery is still exposed. A hosting provider with backups that are never tested is still exposed. A hosting provider with production and backup data vulnerable to the same root-level compromise is still exposed. A hosting provider that cannot restore quickly during an incident is still exposed.
The Dirty, Yet Clean, Truth: AI Is Now Part of the Threat Cycle
There is another uncomfortable thread running through these entire weeks of compromise. AI was not sitting on the sidelines. It was part of the story.
The dirty, yet clean, truth is that AI is now involved on both sides of the security equation. On the defensive side, researchers are using AI-assisted tools to identify complex bugs faster, analyze old code paths, and prepare clearer disclosures. In the case of Linux Copy Fail, AI reportedly helped researchers uncover a bug that had existed for years and assisted in preparing the technical disclosure. That is the cleaner side of AI in security. It can help defenders move faster, find hidden risks, and explain vulnerabilities before they are quietly abused.
But there is a darker side as well.
With the cPanel authentication bypass, AI reportedly helped attackers move faster by lowering the technical bar required to exploit the issue at scale. Attackers no longer need to be elite operators to mass-scan for exposed servers, automate exploit attempts, chain together public details, generate scripts, and deploy ransomware workflows across vulnerable infrastructure. AI can compress the timeline from disclosure to weaponization, scanning, exploitation, and monetization.
That matters because the hosting industry has historically relied on a gap between vulnerability discovery and mass exploitation. That gap is shrinking. AI gives legitimate security teams better analysis and faster response, but it also gives less sophisticated attackers access to capabilities that once required greater technical skill. The result is a faster, noisier, more dangerous threat environment where exposed infrastructure can be targeted almost immediately.
This is why the conversation cannot stop at patching. Patching is essential, but it is not enough on its own. If AI helps researchers find deeper vulnerabilities and helps attackers automate exploitation, then hosting providers need to assume the next wave of threats will move faster than the last.
That brings the industry back to the same hard truth.
You need layered security. You need monitoring. You need strong authentication. You need clean systems. You need trusted partners. But when AI accelerates the entire attack cycle, you also need disaster recovery that is ready before the attack begins.
Because the future of web hosting security is not simply human defenders versus human attackers.
It is defenders with AI, attackers with AI, and infrastructure caught in the middle.
Securing Web Hosting Against the Next Round of Threats
Security will continue to evolve. Attackers will continue to adapt. AI will make both defense and offense more powerful. New models will give defenders better ways to analyze logs, detect anomalies, and respond faster, but they may also give attackers new ways to automate discovery, refine social engineering, scan for weaknesses, and move faster across exposed systems.
That means hosting providers need to think beyond the threat of the week. The next incident may not look like the last one. It may target a control panel, a kernel, an integration, a plugin, a backup path, an API, an abandoned operating system, or a trusted administrative workflow. The specific method may change, but the operational requirement remains the same.
Protect your systems. Protect your customers. Protect your data. Protect your integrations. Test your restores. Secure your backup access. Keep recovery paths clean. And make sure your backups are ready before you need them.
The next threat may be different. Your response should not be
Subscribe to our newsletter
Get expert backup tips, the latest industry trends, and exclusive updates on all things JetBackup. Be the first to know—delivered straight to your inbox.
