A single night of malicious scripting turned one of Russia's biggest hosting platforms into a cautionary tale about backup architecture. Beget, the country's second-largest .RU registrar, lost virtually all cloud-layer data when intruders reached its infrastructure control plane. The fallout is still spreading across government portals, e-commerce stores, and research sites.
- Attack hit overnight Sunday, November 2, 2026, according to ua.news and therecord.media.
- Intruders accessed Beget's infrastructure management systems and ran data-wiping scripts.
- Cloud VPS, S3 storage, and Kubernetes clusters were erased; binary backups are gone.
- File-level backups survived and are the primary recovery path.
- Over 1,000 servers require manual inspection before returning to production.
How the intrusion unfolded
According to therecord.media, attackers gained entry to the systems Beget uses to manage its own infrastructure. From that vantage point they executed scripts designed to erase data across the cloud platform. Ua.news describes the same event as a compromise of the "architecture's control loop," resulting in shutdown of critical server components and destruction of customer cloud data. Both outlets agree the wipe was deliberate and thorough.
Beget's own statements confirm that virtual private servers, cloud storage, and Kubernetes services took the brunt of the damage. The company also acknowledged losing all binary backups of its virtual servers. File-level backups, however, remained intact. That distinction is the only reason recovery is even on the table.
By Wednesday the provider had started bringing some shared-hosting sites back online. Dedicated servers managed directly by customers were restored earlier, since those boxes sit outside the compromised cloud control plane. Still, Beget warned that full restoration will take "a considerable amount of time" because each of the 1,000-plus servers must be checked by hand for malicious remnants.
Why this matters for infrastructure operators
The Beget cloud wipe illustrates a classic single-point-of-failure scenario. When the management plane that orchestrates VPS, object storage, and container clusters falls, every tenant workload tied to that plane goes dark simultaneously. Binary backups stored within the same control domain offer no protection if the attacker wipes the whole namespace.
File-level backups survived because they lived outside the compromised orchestration layer. That architectural accident — not a deliberate design choice — is now the lifeline for thousands of customers. It also means recovery is granular and slow: each filesystem must be validated, cleaned, and reattached to fresh compute instances.
For defenders, the incident reinforces two lessons. First, backup isolation must be enforced by separate credentials, separate networks, and ideally a separate provider. Second, the management plane itself deserves the same hardening as the workloads it controls: privileged access workstations, just-in-time elevation, and immutable logging that an intruder cannot reach.
Real-world scenario: an e-commerce team on Beget
Say you run a mid-size online store hosted on a Beget VPS with an attached S3 bucket for product images. Your database snapshots were binary images stored in the same cloud project. Those are gone. Your nightly file-level dump of the /var/www directory, pushed to an off-site SFTP server by a cron job, survived. You can rebuild the application server from a clean image, restore the codebase and media from the SFTP copy, and replay the last 24 hours of orders from payment-gateway logs. The store comes back in hours, not weeks — but only because you had an independent file backup.
If you relied solely on Beget's native snapshot feature, you would be waiting for the manual server audit queue with no guaranteed recovery date.
What to watch next
Beget has found no evidence of data exfiltration, but the investigation is early. Watch for any credential-stuffing campaigns that reuse passwords or API keys harvested before the wipe. Also monitor whether Russian regulators mandate architectural changes for critical-infrastructure registrars — similar to the underground-data-center push reported after the Yandex drone strikes. The next few weeks will show whether file-level restores can actually reconstitute complex Kubernetes state, or if many tenants face a full rebuild from source control.
Key takeaways
- Treat the management plane as a Tier-0 asset; compromise there cascades to every tenant.
- Keep at least one backup copy outside the cloud provider's control plane and credential domain.
- Plan for manual, server-by-server validation after a destructive event; automation may be untrusted.
- Rotate all credentials and keys that ever touched the compromised platform, even if exfiltration is unconfirmed.
Frequently asked questions
When did the Beget attack happen?
The intrusion occurred overnight on Sunday, November 2, 2026, according to ua.news and therecord.media.
What data was permanently destroyed?
Binary backups of virtual servers, along with all VPS, S3 cloud storage, and Kubernetes cluster data inside Beget's cloud infrastructure.
Can customers recover their sites?
File-level backups survived and Beget is restoring shared-hosting sites gradually, but each of the 1,000-plus servers must be manually inspected first.
Was any data stolen before the wipe?
Beget says it found no evidence of exfiltration, though the investigation continues and the company urged customers to rotate passwords and access keys.
Which high-profile services went down?
The Naryan-Mar city administration site, Russia's Chestny Znak product labeling system, and the Laboratory of Solar Astronomy at the Russian Academy of Sciences were among the affected services.