The Short Version

  • What happened: Skynethosting voluntarily shut down all cPanel-based services on May 1, 2026 in response to CVE-2026-41940, the CVSS 9.8 cPanel pre-authentication bypass.
  • Customer impact: No advance notice. Some customer servers were still down two weeks later. One reseller publicly reported losing 30 percent of clients during the outage.
  • Support failure: Live chat removed from the company website during the outage. Tickets unanswered for over a week. Status updates generic and vague.
  • Server status: Two servers labeled “deeply affected” with forensic data recovery underway; one potentially a write-off. DirectAdmin-based servers were unaffected (incident was cPanel-specific).
  • Open regulatory question: Whether customer data was accessed before shutdown has not been publicly addressed. Singapore PDPA (three-day window) and GDPR Article 33(2) duties apply to customers operating in those jurisdictions.
  • Industry comparison: Other operators patched cPanel within 2 to 3 hours of the April 28 advisory. Skynethosting chose to take services offline instead but lacked the operational infrastructure to execute that path cleanly.

On May 1, 2026, Skynethosting.Net published a security advisory titled “Critical Security Advisory: Temporary Shutdown of cPanel-Based Services,” signed by Daniel Johnson on behalf of the company’s Security and Infrastructure Team. The advisory stated that all cPanel-based services across the company’s fleet had been preemptively taken offline in response to CVE-2026-41940, the CVSS 9.8 cPanel authentication bypass disclosed on April 28. At the time the advisory was published, the company reported that approximately 15 percent of servers had been restored, with about 30 percent of reseller hosting back online.

By May 9, customers were posting on Web Hosting Talk reporting that their Skynethosting reseller accounts had been down for eleven days. One long-time customer wrote that they had lost approximately 30 percent of their own clients during the outage. Some servers were described in company updates as “deeply affected” and undergoing forensic data recovery. As of May 14, the situation for individual customers was still uneven across the company’s regional fleets. The Skynethosting incident is one of the most visible operator-side failures tied to the cPanel security cycle of April and May 2026, and it provides a concrete picture of what the cost of an inadequate incident response looks like for a hosting provider.

The Decision: Voluntary Shutdown, No Advance Notice

The May 1 advisory frames Skynethosting’s response as a voluntary protective measure. The company’s stated approach was to perform full operating system reloads, apply official vendor patches, conduct comprehensive system integrity audits, and implement additional hardening controls before restoring services. The phrasing in the advisory (“preemptively shut down all cPanel servers as a protective measure”) suggests a deliberate decision rather than a reaction to confirmed compromise.

The decision itself is defensible. With a CVSS 9.8 pre-authentication bypass affecting all running cPanel versions in the window before patching, an operator that genuinely believed it could not patch quickly across its fleet might reasonably choose to take services offline rather than leave them exposed. The relevant question is not whether the decision was reasonable, but whether the surrounding operational response matched the severity of the decision.

Customer accounts in community forums indicate that there was no advance notification before services went offline. The thread on Web Hosting Talk opens with a customer post timestamped May 4, four hours into an unexplained outage of their entire reseller account, with no support availability and no public communication. By the time the company’s official advisory was visible to affected operators, the services had already been down for days.

cPanel Patched Five More CVEs. One Fix Is Already Reported Incomplete.

The Communication and Support Failure

The Skynethosting response had multiple compounding operational failures separate from the technical work of patching and rebuilding. Customer complaints on the Web Hosting Talk thread consistently identified the same problems:

  • Live chat support was removed from the company’s website during the outage window, eliminating the channel customers had previously relied on for incident communication.
  • Ticket queues went unanswered for days. Customers report tickets opened in the first days of the outage receiving no substantive response over a week later.
  • Status updates were vague and generic. Company communications used recurring 24-72 hour recovery estimates that customers described as “meaningless percentages and promised resolution windows that come and go.”
  • No specific compromise disclosure. The official communications did not address whether any customer data had been accessed or exfiltrated during the period before the shutdown, and did not commit to a date by which a definitive answer would be provided.
  • Reasonable customer requests were not fulfilled. Customers requesting basic items, including backups of their own data, reported being ignored.

One customer wrote: “After 11 years with them, YES 11!! I am now seriously considering moving (my vip reseller account in Singapore is not usable for 48hrs now).” Another, after eleven days, posted: “I have received almost no meaningful communication from their support or management team… my clients’ websites have been offline for nearly two weeks, and I’m left without any real support, transparency, or recovery path. This is honestly one of the worst hosting support experiences I’ve had.”

The Servers That Did Not Come Back Cleanly

By May 8, Skynethosting was publishing per-server recovery status to the Web Hosting Talk thread. The breakdown is illuminating, both for what came back quickly and for what did not. Servers including Tania, USVIP1, and Budget4 were reported at 100 percent restoration. Servers including Nicole, Kylie, and Britz were undergoing operating system reloads with cPanel reinstallation and restoration from backup, with estimated completion windows of 24 to 48 hours.

Three servers stand out in the company’s own status reports. Corp1 and USVIP2 were described as “deeply affected,” undergoing data recovery with 24 to 72 hour estimates. Mint2 was reported by community observers as potentially “a write off,” with subsequent company updates indicating it had been patched and brought back online but with ongoing remediation. HKVIP1 was reported to have intact data but required a new replacement server.

As of May 14, nearly two weeks after the initial shutdown, cPanel access remains disabled across the entire Skynethosting fleet. Corp1 and USVIP2 are still listed as undergoing data recovery. Two additional servers, USVIP4 and Corp5, have since appeared in the company’s status updates as pending restoration. The 24 to 72 hour estimated windows published on May 8 have elapsed multiple times over without the list of affected servers closing.

The phrasing “deeply affected” and “forensic recovery” in company status updates, alongside the broader pattern of needing complete operating system reloads on multiple servers, is consistent with infrastructure that experienced either confirmed compromise or sufficient uncertainty about compromise to require ground-up rebuilding rather than patching. Whether customer data on those servers was accessed by attackers before Skynethosting took the fleet offline is a question the company’s public communications have not directly answered.

A useful counterpoint surfaced repeatedly in the forum thread: Skynethosting customers running on DirectAdmin-based servers reported their services were unaffected by the outage. The scope of the incident was specifically cPanel infrastructure, not the entire Skynethosting platform. That distinction underlines that the operational decisions and recovery time involved are tied to one control panel layer, not to a broader infrastructure failure, and reinforces the question of why other operators running comparable cPanel fleets were back to normal operations within hours of the April 28 advisory.

Three cPanel Patches and DirtyFrag Fixes in One Day. Here Is Where Things Stand.

The Customer Cost in Public View

The customer-facing cost of the Skynethosting response is visible in the forum thread in unusually concrete terms. One reseller customer reported losing approximately 30 percent of their own clients during the outage. Multiple customers reported their websites being down for more than a week. Some customers running businesses on Skynethosting infrastructure publicly stated that they were already moving to alternative providers and would not return.

For a hosting provider, customer churn during an extended outage compounds: each day services remain unavailable, more customers reach the point of moving. The 30 percent customer loss reported by one reseller is not the final number for Skynethosting’s overall customer base, but it is a data point on the rate at which trust erodes when operational response fails. For comparison, the Apache Foundation, Cloudflare, and similar internet infrastructure operators have publicly documented incidents lasting hours to a day at most, with detailed post-incident reports and clear timelines. The Skynethosting incident is an order of magnitude longer with substantially less communication.

What Breach Notification Law Would Require Here

The Skynethosting incident touches several legal questions that the company’s public communications have not yet engaged. If any customer data on the “deeply affected” servers was actually accessed by attackers during the pre-shutdown window, GDPR Article 33 imposes a 72-hour notification obligation on each affected customer who is, themselves, a data controller. Article 33(2) imposes a parallel obligation on Skynethosting as a data processor to notify affected controllers without undue delay.

The phrasing the company has used publicly (“preemptive protective measure”) avoids confirming compromise, but does not rule it out. For customers operating with EU residents’ data on Skynethosting infrastructure, the question of whether the 72-hour clock under Article 33 has already started running, and whether Skynethosting has met its Article 33(2) duty to notify them, is not a theoretical one. Similar obligations apply under California’s breach notification law and Australia’s Notifiable Data Breaches scheme.

Singapore’s Personal Data Protection Act is particularly relevant here. Skynethosting’s affected fleet includes servers explicitly identified as SGVIP (Singapore) and HKVIP (Hong Kong) tiers, and the company markets services to customers across Southeast Asia. Under the PDPA, notification to the Personal Data Protection Commission must occur within three calendar days of determining that a breach is notifiable, and notification to affected individuals must occur at the same time or immediately after. The PDPA’s three-day window is stricter than GDPR’s 72 hours in practice, and customers running on Skynethosting Singapore servers face that timeline directly if any compromise of their data on those servers is later confirmed. Skynethosting customers operating in any of these jurisdictions face their own controller-level obligations that depend on what Skynethosting can or will tell them about the compromise status of the servers their data was on.

DirtyFrag: Any User Account Can Become Root on Most Linux Servers. The Exploit Is Public. There Is No Patch.

The Pattern Across the Industry

Skynethosting is not the only hosting provider that took aggressive action in response to CVE-2026-41940, and forum commentary indicates that several other providers patched their fleets within 2 to 3 hours of the advisory becoming available. The relevant comparison is therefore not whether shutting down was reasonable, but how the response was executed.

The technical pace of the cPanel patch itself was rapid: the patch was available on April 28, the day of disclosure. Operators with mature patch workflows applied it within hours. Operators without such workflows faced a more difficult choice between leaving services exposed during an active exploitation window and taking services offline for the time it took to rebuild infrastructure that may have been compromised before the patch was applied.

Skynethosting’s response indicates that the company chose the second path, but did not have the operational infrastructure to execute that path quickly or transparently. The two-week outage window is the most visible measure of that gap. The lack of communication and support is the second. The unanswered question about whether customer data was accessed is the third.

What the Incident Surfaces for the Hosting Industry

The Skynethosting incident is operationally specific, but the structural questions it raises apply broadly. Any hosting provider running cPanel at scale faces some version of the same posture decision when a critical vulnerability surfaces with a 9.8 CVSS score and active exploitation. The cPanel security cycle of April and May 2026 has produced at least three distinct release events and a public commitment from cPanel to weekly security releases for the foreseeable future. The operational pressure on hosting providers to maintain both patch velocity and customer communication, simultaneously, is now the default condition, not the exception.

For providers without pre-existing incident response retainers, tested communication workflows, and clearly defined recovery paths, the choice when a critical CVE lands is between two failures: stay online and accept the exposure window, or take services offline and accept the customer impact of a slow rebuild. Skynethosting demonstrates what the second failure looks like when the underlying capabilities are not in place. The first failure is what produced the 44,000 servers Shadowserver tracked as compromised by CVE-2026-41940 in the days after disclosure.

The next time a CVSS 9.8 cPanel vulnerability surfaces, the operators who do well will be the ones who have already invested in the operational infrastructure to do either of those paths cleanly. The Skynethosting incident is the public reminder that the cost of not investing is concrete and customer-visible, and that the regulatory consequences for the customers who hosted with that provider are not theoretical.