Hosting providers did not spend August learning that they need backups. They spent it learning that a completed backup job and a recoverable system are not the same thing.

A copy can exist and still fail you when the systems required to reach it are unavailable, when the same credentials protect production and recovery, or when the environment around the backup has already been compromised.

That was the pattern across several incidents this month. The backup may have existed, but recovery was still in doubt because the panel, DNS, support systems, credentials, applications, or underlying infrastructure were part of the same failure domain.

When the Panel Dies With the Servers, the Restore Is a Rumor

Namecheap’s Phoenix Outage

On August 13 and 14, a major storm contributed to a cooling-system failure at RadiusDC’s Phoenix facility. RadiusDC instructed Namecheap to take services offline to protect the hardware, and the incident ran for roughly 30 hours. Incident reporting indicated no data loss, but the outage affected Shared Hosting, VPS, Dedicated Hosting, EasyWP, Private Email, DNS infrastructure, and support services.

The important part was not simply the weather. It was how much of the recovery path depended on the same environment. Websites hosted elsewhere could still become unreachable when their DNS depended on Namecheap infrastructure, while customers needing help also faced difficulty reaching support systems during the outage.

When Restoring Can Make Things Worse

As EasyWP returned in stages, dashboards became available before every underlying service had fully recovered. That created one of the most dangerous moments in any outage: the point where restoring a backup feels like action, even when the data itself may still be intact.

Operational guidance reported during the incident was to wait rather than immediately restore, recreate a site, or make unnecessary changes while services were still recovering. If the underlying database is temporarily unreachable, restoring an older backup does not repair the database connection. It can instead replace intact current data with an older copy while leaving the real problem unresolved.

That is the distinction hosting providers have to design for. A backup can be perfectly healthy and still be operationally useless if the console that initiates the restore, the DNS that directs traffic, and the support systems coordinating the response all depend on the same facility.

A copy that exists but cannot be reached when the primary environment fails is not much of a recovery plan. It is simply another piece of inventory waiting for the rest of the stack to come back.

Cloud Services Have Failure Domains Too

Smaller incidents later in the month reinforced the same point. DigitalOcean reported Spaces accessibility problems on August 21, followed by public API and Cloud Control Panel errors on August 24.

These were not Phoenix-scale outages, but they demonstrated that both storage access and the control planes used to manage infrastructure can become temporarily unavailable.

The lesson is not that every backup destination will fail. It is that recovery architecture has to assume parts of the management and storage stack eventually will. The copy has to live somewhere you can still reach after the primary environment goes dark.

Disaster Recovery With Production Credentials Is Another Production Copy

Gunra Went After Recovery Too

On August 10, CISA, the FBI, and partner agencies published an advisory on Gunra, a Conti-derived ransomware-as-a-service operation using double extortion.

The advisory reads almost like a recovery architecture review because the attackers did not stop at encrypting production systems. They targeted the infrastructure intended to bring the business back.

Gunra affiliates have exploited known vulnerabilities in internet-facing VPN and firewall appliances, moved laterally through compromised environments, and attacked recovery systems after gaining access.

In one incident, attackers deleted backup and archived data at both the primary data center and the disaster recovery center before and after deploying ransomware.

A Second Location Does Not Mean a Second Line of Defense

The second location did not create a meaningful second line of defense because the attackers were still able to reach and destroy recovery data in both environments.

That is an important reminder that geographic separation alone does not create backup independence. A second location is not truly independent when the same compromised identity, administrative path, or trusted infrastructure can reach it.

Moving a copy to another data center helps with physical failures. It does not necessarily protect against compromised credentials or administrative access that spans both sites.

MFA Can Be Compromised Too

MFA did not automatically solve that problem either. According to the August 10 advisory, Gunra modified authentication processing on a VDI portal so that an attacker-designated one-time password would succeed.

MFA could still appear to be enabled while the authentication control underneath it had already been altered.

That matters directly to backup design because a green security indicator is not proof that the destination still belongs exclusively to you. If an attacker can alter authentication, inherit an administrator session, or reuse the same identity across production and disaster recovery, the backup environment remains inside the same blast radius.

Offline, Immutable and Tested

CISA’s recommendation is specific: maintain tested, offline, immutable backups in a physically separate and segmented location. Those words describe different parts of the recovery problem and should not be treated as interchangeable marketing terms.

Offline means production systems and compromised administrative sessions cannot simply reach the recovery copy. Immutable means protected backup data cannot be overwritten or deleted during its retention period. Tested means somebody has actually completed a restore from that copy and proven that the process works.

A successful backup job log only proves that data moved from one place to another. It does not prove that the data can still be reached after an attack, that the attacker cannot delete it, or that the business can successfully restore from it.

If you have never restored from a copy the attacker cannot see, alter, or destroy, you may have a replica. You do not yet know whether you have a recovery plan.

A Patched Box Is Not a Clean Box

The rest of August brought a series of vulnerabilities that all point toward the same operational lesson. Patch quickly, but do not assume installing the update automatically returns the system to a trusted state.

Plesk: Reseller to Root

Plesk published remediation on August 6 for CVE-2026-64637, a critical privilege-escalation vulnerability that allows an authenticated reseller to obtain an administrator session with root-level control through the XML-RPC API.

The vulnerability carries a CVSS score of 9.9, reflecting how quickly a relatively limited hosting account could become a complete panel compromise.

The same remediation cycle addressed CVE-2026-64636, a blind SQL injection vulnerability that can allow an authenticated user to read data from the Plesk database. Plesk fixed both issues in versions 18.0.79.5 and 18.0.80.1.

For a hosting provider, a reseller account is not just another user account. It may sit above multiple customer accounts and interact with backup jobs, destinations, API tokens, DNS, account provisioning, and other privileged systems.

Once an attacker moves from reseller access to administrator-level control, the risk extends beyond the websites currently hosted on the server. An attacker may be able to alter backup configuration, redirect destinations, remove restore points, or quietly make the next recovery attempt less reliable.

Another Plesk Vulnerability Arrives August 25

Plesk disclosed another serious vulnerability on August 25. CVE-2026-65646 affects DNS zone-management functionality on Plesk for Linux and can allow a hosting customer with DNS-management privileges to read arbitrary files from the server.

Plesk warned that exposed files could include administrator and database credentials, potentially allowing full access to the panel and its database. The vulnerability is fixed in Plesk 18.0.79.8 and 18.0.80.4.

This also makes unmanaged VPS patch lag a provider problem, even when responsibility for the operating system technically belongs to the customer. The server still sits on the provider’s network, can still be used to attack other systems, and may still interact with provider-controlled services.

The incident clock begins when the vulnerability becomes actionable and remediation becomes available, not when the tenant eventually reads the changelog.

WordPress: Updating the Plugin Is Only Step One

miniOrange SAML SSO Authentication Bypass

WordPress repeated the same lesson at the application layer with the miniOrange SAML SSO vulnerabilities CVE-2026-61979 and CVE-2026-15981.

The flaws can be chained so that a forged or improperly validated SAML response results in an unauthenticated WordPress administrator session.

The free edition was patched in July, but the paid editions follow separate version lines even though they share the same WordPress.org slug. That makes a simple version check unreliable because a Plugins screen may look current while the actual paid edition installed on the site remains vulnerable.

miniOrange provided Patchstack with the full edition matrix on August 18, and Patchstack published its broader public analysis on August 21. By August 24, active exploitation attempts targeting the vulnerabilities were being reported.

Providers should identify the actual miniOrange edition in use, apply the correct update package, and review administrator sessions, user creation, privilege changes, and other account activity.

The patch closes the vulnerability, but it does not revoke every attacker session or undo changes already made before the update was installed.

Elementor Pro: The Shell Can Survive the Patch

Elementor Pro brought a more familiar WordPress failure. CVE-2026-32475, rated critical with a CVSS score of 9.0, is an unauthenticated arbitrary file-upload vulnerability affecting Elementor Pro 4.2.1 and earlier. It was fixed in version 4.2.2 on August 19.

A crafted request can allow an attacker to upload a malicious PHP file into Elementor-managed upload storage. Updating the plugin closes the upload vulnerability, but it does not automatically remove a shell that may already have been placed on the server.

At disclosure, there was no confirmed exploitation in the wild, but that should be treated as a hunting window rather than permission to ignore the filesystem.

Providers should push the fixed version, inspect relevant upload directories and logs, and investigate unexpected PHP files or changes. If a shell or other sign of compromise is discovered, the safest path may be to rebuild or restore from a point known to predate the intrusion rather than trusting the patched system simply because the vulnerable code is gone.

Zimbra: Closing the Door Does Not Remove the Intruder

CVE-2026-73570 Moves Into Active Exploitation

Mail servers carried the same risk with a much larger operational footprint.

Zimbra CVE-2026-73570 is an unauthenticated command-injection vulnerability triggered through crafted SMTP requests when the optional zimbra-snmp package is installed and SNMP notifications are enabled.

Zimbra patched the flaw in ZCS 10.1.20 on July 20. CERT Polska warned of active exploitation on August 17, and CISA added CVE-2026-73570 to the Known Exploited Vulnerabilities catalog on August 21.

By August 25, threat-intelligence reporting indicated that more than 270 Zimbra instances had already shown signs of compromise.

Patch, Then Hunt

Updating Zimbra closes the vulnerable entry point, but it does not remove a webshell or persistence mechanism placed before the update.

Providers should inspect logs and the Jetty web application directories at /opt/zimbra/jetty/webapps/ and /opt/zimbra/jetty_base/webapps/ before declaring the environment clean.

This is the recurring theme throughout August. Patching tells you the vulnerability is no longer open. It does not tell you who walked through it yesterday.

Sakura Internet: The Blast Radius Goes Beyond Hosting

583 Rental Server Accounts

Sakura Internet showed why containment also has to extend beyond the hosting fleet itself.

Its August 17 notice described unauthorized access affecting 583 Rental Server accounts, with malware discovered in customer-accessible areas.

Up to 1.36 Million Member Records Potentially Exposed

A separate disclosure on August 19 described possible unauthorized access to Sakura’s sales-management system before August 9.

Up to 1,360,563 member records were potentially in scope, but that number represents possible exposure rather than confirmed theft. Sakura said it had not confirmed data exfiltration, and the affected system did not contain payment-card information. The incident has not been attributed to ransomware.

The two Sakura incidents should not be collapsed into a single breach claim, but together they illustrate an important architectural problem.

Containing production servers does not automatically mean billing, customer databases, internal management systems, or support infrastructure are outside the incident. Those systems remain separate only until shared credentials, a jump host, monitoring infrastructure, administrative tooling, or another trusted relationship brings them into the same blast radius.

Patch, Investigate, Then Recover

The operating model therefore has to go beyond patching the panel, plugin, or mail server.

Patch the vulnerability, but then treat the environment as potentially compromised until investigation provides evidence that it is clean. Review authentication logs, administrator accounts, sessions, filesystem changes, scheduled tasks, backup configurations, API credentials, and other persistence opportunities appropriate to the affected system.

When compromise is confirmed, recovery may require more than removing malware. Credentials may need to be rotated, sessions revoked, systems rebuilt, and data restored from a known-good point before the attacker entered the environment.

That is where the quality and independence of the backup suddenly matter much more than whether last night’s job showed green.

Recovery Is the Copy That Does Not Need the Failed Stack

August’s incidents looked very different on the surface. One involved a cooling failure, another involved ransomware, while others involved panel privilege escalation, WordPress authentication bypass, arbitrary file uploads, mail-server compromise, and unauthorized access to business systems.

Underneath, they expose the same recovery problem. The restore has to work while the panel is unavailable, the backup has to survive credentials that production still trusts, and the system being restored has to come from a point the attacker did not control.

That requires an independent copy using separate credentials, stored somewhere production cannot simply delete it, with a restore path that does not depend entirely on the failed panel or management environment.

It also requires an actual restore test rather than confidence based on a completed backup job. Scheduling the job is not the test. Successfully bringing the data back and proving that applications, databases, credentials, and services work as expected is the test.

3-2-1 Backup Comes Full Circle

This brings us back to a strategy that has been around for roughly two decades: 3-2-1 backup. Keep at least three copies of your data, on two different types of storage, with at least one copy offsite.

For years, the industry moved aggressively toward online and cloud-based backups because they are faster, easier to manage, and easier to restore. That transition solved many operational problems, but it also created new relationships between production credentials, backup destinations, control planes, cloud APIs, and administrative access.

As ransomware, credential theft, supply-chain attacks, compromised control panels, and AI-assisted attacks become more prevalent, the 3-2-1 strategy is coming full circle.

It is no longer enough to ask where the backup is stored. Providers also need to ask who and what can reach it, modify it, delete it, or prevent it from being restored.

Separating Recovery With JetBackup

JetBackup provides the layer needed to separate recovery from the system being protected. Backups can be sent away from the server, away from the facility’s single failure path, and away from credentials shared with production.

Where ransomware is part of the threat model, properly configured Object Lock adds another critical layer by preventing protected backup objects from being overwritten or deleted during their retention period, even when production credentials are compromised.

JetStorage gives providers a destination for that independent copy, helping ensure the only usable recovery data is not sitting on the same server they may ultimately need to rebuild.

Could Offline Storage Make a Comeback?

As attacks become more sophisticated, there is also an interesting question worth asking about where backup architecture goes next.

Could truly offline storage, including tape, make a broader return as organizations rethink the “2” and “1” in the 3-2-1 strategy and place more value on copies that are physically or logically unreachable from production?

Cloud storage and Object Lock provide powerful protections, but the renewed focus on ransomware-resistant recovery is also reminding the industry why offline copies existed in the first place. The future may not be cloud or offline storage. For critical infrastructure, it may increasingly be cloud and offline storage.

The technology may change, but the principle has not. Keep multiple copies, separate them, move at least one offsite, make critical recovery data immutable or otherwise unreachable from production, and regularly test a restore that does not require the panel or infrastructure that just failed.

Because the best backup is not simply the one that was completed last night. It is the copy that remains intact, reachable, and recoverable when everything around it does not.

That is the last line of defense August actually tested.