Beget says attackers reached the management layer of its hosting infrastructure and ran wiping scripts, turning a November 2 outage into a recovery operation that includes lost cloud data and destroyed VPS disk-image backups. In a November 3 update, the provider said file backups survived, but access to them still depends on restoring and checking the underlying infrastructure.
That distinction matters to customers deciding whether they can simply restart a server. A surviving file backup may provide material for rebuilding a service; it does not mean the original virtual machine, its configuration and every dependent service are ready to return.
From a service outage to a management-layer compromise
Beget initially described a major incident and manual work in its data centers. On November 2, it confirmed a cyberattack and said recovery of name servers and email was in progress. Its next detailed statement, published November 3 at 12:15 UTC, added the decisive detail: attackers had gained access to the infrastructure’s management layer before running destructive scripts.
The provider has not publicly identified the entry route, attacker or particular vulnerability. The statement supports a destructive infrastructure compromise; it does not establish ransomware, a ransom demand or a connection to a previously disclosed software flaw. Those missing details should not be filled in from the outage alone.
The backup that survived is not the backup that was lost
In its November 3 account, Beget said data in its cloud infrastructure—including VPS, S3 and Kubernetes—had been lost. It separately said VPS file backups were preserved, while binary VPS backups were completely lost. CDN and IP configuration was also lost, according to the provider.
A disk image can preserve the structure needed to recreate a machine. A file backup can preserve content without recreating that whole running environment. Beget’s wording therefore describes different recovery paths, rather than a simple promise that everything can be rolled back. The exact contents, age and usability of an individual customer’s backup still require confirmation.
- VPS disk-image backups: Completely lost. Check: A rebuild plan rather than an assumed image restore.
- VPS file backups: Preserved; access depends on infrastructure recovery. Check: Available snapshot date, contents and restoration route.
- Shared hosting: Almost all sites preliminarily assessed as recoverable. Check: Actual restoration and application checks for each site.
- Cloud S3 and Kubernetes data: Reported lost. Check: Independent copies and service-specific recovery options.
The provider said more than 1,000 servers needed manual checks for hidden weaknesses and malicious scripts. This explains why finding a surviving copy and making it available are separate milestones. Its preliminary estimate for shared-hosting recovery is a provider assessment, not proof that every site has already returned intact.
DNS and email are separate parts of the recovery
Beget reported that customer-administered dedicated servers had returned and that 80% of its mail infrastructure was restored. The latter is an infrastructure progress figure, not a guarantee that every mailbox works. Its ten-hour estimate for full email operation was a forecast made in that statement.
The company also said customers could change A, MX and TXT records for .ru, .рф and .su domains registered through Beget and using its name servers. International-domain management was still being restored. A DNS change can direct visitors or mail to a prepared replacement, but it cannot recreate missing files or make an empty replacement server a working website.
What affected customers can do now
Record which services are actually affected, preserve local deployment files and independent backups, and ask support what recovery material exists for each account. Before changing DNS, prepare and verify the destination service, including certificates, application data and email routing. Keep the previous records so the change can be reviewed.
Beget recommends changing passwords, access keys and other credentials that may have been stored on its servers. Rotate those credentials through trusted account pages, update legitimate applications that use them, and revoke old values. An outage is also an opportunity for fake recovery messages: use a known support route rather than a link asking you to upload a backup or disclose a secret.
The provider said its available evidence showed no attempts to download or alter data on servers holding user data. That is a preliminary observation within its investigation, not an independent assurance that no information was exposed. Its recommendation to rotate credentials remains relevant while the scope is being established.
The practical lesson is the difference between having a backup and controlling an accessible recovery path. For context on another hosting compromise and its different evidence, see our FirstVDS investigation. Beget has not yet supplied a firm completion time for all services.
References
- Beget. Incident and service recovery update. Official channel, November 2, 2026.
- Beget. Current situation: management-layer compromise, backups and recovery. Official channel, November 3, 2026, 12:15 UTC; accessed November 3, 2026.
