Russia | November 10, 2026

The Beget cyberattack has exposed the serious consequences of a destructive intrusion against a cloud and hosting provider after attackers gained access to the company’s infrastructure management systems and launched malware designed to erase server data. The incident, which began overnight on November 1–2, disrupted hosting services, affected cloud environments and forced Beget to undertake a large-scale recovery operation.

Beget said the attackers reached the management layer of its infrastructure and executed data-zeroing scripts. The company disconnected its servers from the network after detecting the intrusion, but the attack had already caused extensive damage. Virtual private server (VPS) data, cloud storage, Kubernetes environments and related infrastructure configurations were affected.

The incident has also exposed the risks of relying on a single hosting provider for critical business operations. Websites, online stores, email services and other digital projects that depend on Beget experienced disruption while the company worked to rebuild affected systems.

The provider’s recovery process has progressed in stages. However, some backup data was lost, and the company has warned that not every VPS environment can be fully restored. On November 9, Beget announced that surviving VPS backups could be downloaded through its control panel.

The Beget cyberattack is therefore an important case study in destructive malware, cloud infrastructure security and the limitations of backup strategies when attackers reach centralized management systems.

1. Attackers Compromised Beget’s Infrastructure Management Layer

Beget’s official incident timeline places the beginning of the attack at approximately 02:00 Moscow time on November 2, 2026. The company described this as the estimated time when attackers gained access to its management servers.

At approximately 02:30, the attackers launched malware designed to delete data from servers. Beget estimated that it detected unauthorized access at around 02:40 and disconnected all servers from the network at approximately 02:55 to prevent the attack from spreading further.

The company began its investigation and recovery work at approximately 03:00. Its first customer notification followed at 04:50 through its official Telegram channel.

These times come from Beget’s own incident timeline and are estimates rather than independently established forensic timestamps.

The management-layer compromise is particularly significant. Infrastructure management systems can provide administrative control over large numbers of servers and services. If attackers obtain sufficient privileges in such an environment, they may be able to disrupt multiple customer systems without compromising each customer’s website individually.

In this case, Beget said the attackers gained access to the management layer of its wider architecture before launching scripts that erased data.

The Beget cyberattack illustrates how a compromise of centralized infrastructure controls can produce consequences far beyond an ordinary website intrusion.

Beget has not publicly disclosed the initial access method. It has also not identified a threat actor or published evidence establishing how the attackers obtained their access.

2. Cloud Services and Customer Data Environments Were Wiped

The damage extended beyond temporary service unavailability.

Beget said data associated with its cloud infrastructure, including VPS, S3 storage and Kubernetes services, was lost. The company also reported the loss of CDN settings and IP configurations.

The VPS impact was especially serious because the provider’s binary backups were completely lost. File-level backups survived partially, but Beget’s November 6 assessment indicated that these would be available for only approximately half of VPS users.

This distinction is important. A binary backup and a file-level backup are not necessarily interchangeable. Depending on what survives, customers may need to rebuild operating systems, applications, configurations and services even when some files can be recovered.

BleepingComputer reported that Beget described full recovery of all VPS data as impossible under its then-current assessment. The provider also explained that matching surviving backups to individual users was technically complex.

The Beget cyberattack therefore caused both operational disruption and potential permanent data loss. Customers whose data was not preserved in surviving backups may have to reconstruct systems from other copies, source repositories or local records.

The November 9 update provides a partial recovery route: Beget said VPS backups could then be downloaded from its control panel. That does not mean every affected customer has a complete backup or that all VPS services and data have been restored.

3. More Than 1,000 Servers Required Manual Security Checks

Restoring services after destructive malware is not simply a matter of restarting machines.

Beget said more than 1,000 servers required manual inspection before being returned to operation. The company adopted a cautious approach, treating potentially affected infrastructure as compromised and checking for vulnerabilities and hidden malicious scripts.

This approach can extend recovery time, but it addresses an important risk: bringing a compromised server back online without removing malicious components could allow attackers to regain access or repeat destructive activity.

The Record reported that Beget was checking servers individually and removing malicious files while restoring data integrity. BleepingComputer later reported the provider’s intention to clean and rework potentially vulnerable parts of its infrastructure.

The provider’s recovery timeline showed that 35% of shared hosting and 15% of Beget-managed dedicated servers had been restored by November 4. By November 5, those figures had increased to 60% and 40%, respectively.

These are dated recovery figures, not a statement of the provider’s exact current restoration percentage on November 10. Beget’s November 9 update separately confirmed that VPS backups had become downloadable through the control panel.

The Beget cyberattack demonstrates why recovery after a destructive intrusion can take substantially longer than the initial containment operation. Infrastructure must be inspected, rebuilt, tested and repopulated with data before it can safely support customers again.

4. Businesses and Online Services Experienced Wider Disruption

Beget is a major Russian hosting, cloud and domain-registration provider. BleepingComputer reported that it serves more than 200,000 customers, including online stores, media organizations and educational services.

The Record reported that the disruption affected hundreds of websites and online services across Russia. Reported examples included the official website of the Naryan-Mar city administration, Russia’s Chestny Znak product-labeling system and a website operated by the Laboratory of Solar Astronomy at the Russian Academy of Sciences.

The impact illustrates how hosting providers function as shared infrastructure for organizations that may have no direct relationship with one another.

A business might operate its website, email, databases or online services through a hosting company without managing the provider’s underlying infrastructure. When that provider suffers a major outage, customers can lose access to services even if their own applications were not directly attacked.

Small and medium-sized businesses can be particularly exposed when they rely on a single provider and lack tested alternatives.

The Beget cyberattack also shows why organizations should identify which parts of their operations depend on external hosting, DNS, cloud storage, email and domain-management services. A disruption in one provider’s management environment can affect several dependencies at once.

5. Beget Found No Evidence of a Customer Data-Theft Operation

One important distinction separates this incident from many conventional data breaches.

Beget said its investigation had not found evidence that attackers attempted to download or modify information stored on servers containing customer data. The company described the incident as apparently focused on destruction rather than data theft.

That statement should be treated as the provider’s current assessment, not independent proof that no information was accessed or copied under any circumstances.

The initial access method, attacker identity and motive remain publicly undisclosed. No hacking group had publicly claimed responsibility in The Record’s November 4 report, and BleepingComputer’s November 9 coverage did not identify a responsible group.

The absence of a confirmed theft operation does not eliminate customer security risks. Credentials, access keys and other secrets may have been stored on affected systems. Beget advised customers to change passwords, access keys and other credentials that might have been present on compromised servers.

The Beget cyberattack therefore raises two separate questions: what data was destroyed, and whether any credentials or sensitive information could have been exposed during the intrusion.

Customers should not assume that the absence of confirmed data theft means every credential associated with an affected environment is safe.

6. Seven Critical Security Risks for Hosting Customers

The incident highlights several risks that organizations using cloud and hosting services should consider.

1. Permanent data loss: If production systems and their backups are compromised or erased, organizations may be unable to recover all files, databases or application states.

2. Centralized management compromise: Administrative access to a provider’s management layer can create a path to disrupt multiple customer environments at once.

3. Credential exposure: Passwords, API keys, SSH keys and other secrets stored on affected systems may require rotation, even when data theft has not been confirmed.

4. Business interruption: Website downtime, unavailable email and inaccessible cloud applications can interrupt sales, customer support and internal operations.

5. Backup dependency: Organizations that rely exclusively on backups held within the same provider environment may discover that those copies are not sufficiently isolated from destructive attacks.

6. Recovery complexity: Restoring files is not always enough. Businesses may also need to recreate server configurations, network settings, access controls and application dependencies.

7. Supply-chain concentration: Multiple organizations may depend on one infrastructure provider. A single provider-level incident can therefore create a broad downstream impact.

The Beget cyberattack demonstrates why these risks should be addressed before an incident occurs rather than after a provider begins emergency recovery.

7. Recovery Progress and the November 9 Backup Update

Beget’s recovery timeline shows how the provider restored services in stages.

On November 2, unmanaged dedicated servers and name servers were restored. On November 3, more than 80% of mail infrastructure had been recovered, and the webmail interface was available. Shared hosting recovery began in stages, with the first websites returning on November 4.

The control panel was relaunched with limited functionality on November 7.

A further update on November 9 stated that VPS backups could be downloaded through the control panel. This was a meaningful step for affected customers because surviving backup files could provide a route to recover at least part of their environments.

However, Beget’s earlier assessment said VPS file backups would be available for approximately half of VPS users, while binary backups had been lost. The provider also described the technical difficulty of matching surviving backup data to individual customers.

The Beget cyberattack recovery process therefore remains more complicated than restoring a service dashboard or bringing a server online. Customers may still need to rebuild systems, validate recovered files and recreate configurations.

The company has also said it notified law enforcement and government agencies and was working with cybersecurity specialists. It has not publicly provided a complete forensic explanation of the intrusion.

What Beget Customers Should Do

Organizations that used Beget services during the incident should first check the provider’s official status page and control panel for service-specific recovery information.

They should also take several precautionary steps:

• Change passwords and rotate API keys, SSH keys and other credentials that may have been stored on affected servers.
• Review access logs and authentication records for suspicious activity.
• Verify recovered backups before restoring production workloads.
• Check application files, scheduled tasks, server configurations and administrative accounts for unexpected changes.
• Rebuild critical systems from known-good sources where integrity cannot be established.
• Maintain independent backups outside the affected provider environment.
• Prepare a recovery plan that includes alternative hosting, DNS and communication arrangements.

Customers should obtain recovery instructions directly from Beget’s official website and support channels. They should be cautious of unsolicited messages claiming to offer emergency backup restoration or account recovery.

Conclusion

The Beget incident shows how destructive malware can threaten an entire hosting ecosystem when attackers gain access to centralized infrastructure management systems. The attack disrupted cloud services, damaged customer environments and forced the provider to inspect and rebuild a large server estate.

Although Beget reported no evidence that attackers attempted to steal customer data, the loss of VPS binary backups and the limited survival of file-level backups create serious recovery challenges. The November 9 announcement that surviving VPS backups could be downloaded offers a recovery option, but it does not guarantee complete restoration for every customer.

The Beget cyberattack remains an evolving incident. The initial access method, responsible actor and full extent of customer-level data loss have not been publicly established. For hosting customers worldwide, its central lesson is clear: backups must be isolated from production infrastructure, administrative access must be tightly controlled, and recovery plans must be tested against destructive attacks.

Source note: This report draws on Beget’s official security and recovery timeline, its official Telegram updates, and reporting by The Record from Recorded Future News and BleepingComputer. The initial access method, attacker identity and motive remain unconfirmed. Beget’s statement that it found no evidence of data theft is attributed to the company and should not be interpreted as independent forensic confirmation.

NewsFlayer — Bringing You the Latest Cybersecurity News from Around the World.