At two in the morning, attackers gained management access to a major hosting provider. At 02:30, they launched a data destruction program. At 02:55, servers were disconnected from the network. Twenty-five minutes was all it took for thousands of websites and services to face a catastrophe.
In the early hours of November 2, 2026, Russian hosting provider Beget was hit by a devastating cyberattack.
This was not a standard DDoS attack, where servers are overwhelmed with traffic. Nor was it classical ransomware, where files are encrypted for a payout.
The attackers gained access to the infrastructure's management plane and deployed malware designed specifically to purge data.
Beget officially confirmed this scenario.
Chronology of the Twenty-Five Minutes
According to the timeline published by the company:
- 02:00 — Estimated start of the attack and unauthorized access gained to management servers.
- 02:30 — Launch of the data destruction script/software.
- 02:40 — Detection of unauthorized access.
- 02:55 — Servers disconnected from the network to halt the spread of the attack.
At 03:00, the investigation and recovery efforts began.
By that point, the damage had already been dealt.
The incident affected virtual hosting, cloud servers, storage volumes, DNS, and mail infrastructure.
Among the affected services was the BelkaCar car-sharing platform. Issues also arose with access to the "Chestny Znak" information portal, though the tracking system itself, according to its operator, continued to function.
Beget serves over 200,000 clients. According to an October market study, approximately 14.7% of domains in the .RU zone were linked to the company, including parking domains and redirects.
This does not mean every seventh Russian website stopped working, but it highlights the scale of internet projects' reliance on a single provider.
How Do You Destroy a Cloud in 25 Minutes?
Imagine a massive warehouse with thousands of rooms.
Each room has its own door and lock. But somewhere, there is a central master console that allows you to simultaneously open, lock, or reconfigure the entire complex.
In server infrastructure, this role is played by the Control Plane.
Through it, automated systems can create virtual machines, provision storage disks, change network settings, manage repositories, and delete resources.
If an attacker secures sufficiently high privileges, they do not need to compromise every single virtual machine individually.
They can impact the infrastructure centrally.
At the same time, wiping massive amounts of data does not always require physically overwriting every single byte.
Depending on storage architecture, it is often enough to delete virtual disks, corrupt critical metadata, or destroy the information required to access the data.
The system stops seeing the contents, even though the physical storage drives continue to exist.
This is a technical explanation of a potential mechanism, not the officially established action sequence of Beget's attackers. The company has not yet disclosed specific tools or the initial penetration vector.
The Scariest Loss: Backups
On November 3, Beget reported data loss across its VPS, S3, and Kubernetes cloud infrastructure.
Binary backups of VPS were also lost.
However, file-level backups remained intact, leaving a window for partial recovery.
The distinction is fundamental.
A binary backup of a virtual server allows for the restoration of an entire machine image. A file backup contains individual files, but not necessarily the complete disk structure, the states of running services, or required configurations.
Therefore, having a file archive does not automatically mean a server can be brought back to life with a single click.
On November 5, Beget announced that the majority of VPS file backups had survived and preparations were underway to distribute them to clients.
Herein lies the primary engineering challenge.
If working data and the backup system rely on the same management plane, compromising that plane can simultaneously destroy both the original data and the path to recovery.
Three copies on three disks will not save you if all three can be wiped out using a single set of administrative privileges.
A Million Route Changes: What Happened to the Network?
The attack exhibited another unusual symptom.
According to Kommersant, citing RIPEstat data, nearly one million route announcement changes were observed within Beget's network routing over the course of a single hour. For comparison, the previous 90-day peak did not exceed 20,000.
This is a colossal anomaly.
BGP is the protocol autonomous networks use to exchange information about available internet paths.
Sudden routing shifts can accompany the shutdown of network nodes, emergency reconfiguration, or router malfunctions.
Could the attackers have interfered with network hardware? Theoretically, yes.
Could the engineers themselves have caused the routing spike while trying to isolate the infrastructure? That scenario is also possible.
However, published data does not yet allow for a definitive cause to be established.
The BGP anomaly deserves a separate study. Attributing it to the attackers' actions without proof would be premature.
### Could the October PHP Vulnerability Be the Cause?
In October, we examined dangerous server software and AI gateway vulnerabilities.
A logical question arises: did the attackers use a similar path to infiltrate Beget?
Potential entry points are numerous: administrative panels, stolen tokens, vulnerable services, employee workstations, remote access systems.
However, Beget has not named the initial vector of the attack.
Therefore, tying November's infrastructure destruction to any specific PHP vulnerability is currently unfounded.
The key confirmed fact is different: the attackers gained access to infrastructure management. How they did it remains unknown.
How to Protect Your Own Server from a Similar Catastrophe?
A small project does not need three data centers and a million-dollar budget.
It requires an architecture that prevents a single incident from wiping out everything.
First. Independent backups.
Databases, configurations, recovery keys, and files must be regularly backed up outside of your primary hosting provider.
Second. Deletion protection.
For backups, storage vaults utilizing Object Lock and immutability modes are extremely useful. For instance, S3 Object Lock Compliance prevents the deletion of a protected object version until a set retention period expires, even by an account administrator.
However, such protection requires proper configuration and does not replace separate credentials and access control.
Third. Independent DNS management.
If your website, email, DNS, and backups all reside with a single provider, an outage there can paralyze your entire project.
The ability to quickly redirect a domain to a secondary site must remain independent of your primary server.
Fourth. Verified recovery.
An archive that has never been tested for restoration is nothing more than wishful thinking.
You must periodically spin up a test server from a backup to verify that applications launch, databases open, and essential services function correctly.
Fifth. Limitation of administrative privileges.
Mass infrastructure deletion should never depend on a single token or a single user account. Critical operations require a separation of duties, independent verification, and emergency access lockout capabilities.
Why This Matters to Every VPN and AI Service Owner
Imagine running a VPN server with hundreds of clients.
It stores configurations, access keys, routing settings, and billing data.
One destructive attack on the provider's infrastructure — and the server vanishes.
If your backup resides in that same environment, your ability to quickly restore operations vanishes with it.
For an AI gateway, the situation is identical: the loss of configurations, secrets, user databases, and payment histories can halt your entire service.
Therefore, independence is not merely about being able to choose another cloud provider.
True independence begins with the ability to walk away from your current provider along with your data and restore operations without their involvement.
### What Happened After the Attack?
Beget's recovery efforts spanned several days.
By November 5, the company announced the launch of 60% of its virtual hosting and 40% of its self-managed dedicated servers.
Billing for affected services was suspended during the downtime.
The company continued inspecting servers and restoring backups.
This is grueling work: once a management plane is compromised, you cannot simply switch the hardware back on without making sure malicious code and unauthorized privileges have been completely purged.
The Main Takeaway
In previous "Glass Bridge" investigations, we examined Linux vulnerabilities, AI gateways, and compromised official software updates.
Beget demonstrated the next tier of threats.
Sometimes, an attacker does not need to target an individual server.
It is enough to take control of the system upon which thousands of servers depend.
Twenty-five minutes can destroy an infrastructure built over years.
Consequently, the primary question for any digital business owner should not be "how well-known is my hosting provider?"
Instead, it must be far more specific:
"Will I be able to restore my entire project tomorrow if this hosting provider disappears today?"
If the answer is unknown, it is high time to run an audit. While it is still a routine drill rather than a real catastrophe.
Glass Bridge | November 6, 2026
Sources
- Beget — Official timeline of the cyberattack and recovery: https://beget.ru/ru/security
- Beget Official — Statements regarding cloud data loss and intact file backups: https://t.me/s/beget_official
- Kommersant, November 2, 2026 — Scale of the outage and BGP anomalies: https://www.kommersant.ru/doc/9079245
- AWS — S3 Object Lock documentation: https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html