Massive fall of Beget: cyberattack left thousands of sites

**November 2, 2026, one of the largest hosting providers in Russia, Beget, faced a massive failure. No longer open sites, virtual servers, mail and control panels. A few hours later, the company reported a massive cyber attack. We’re looking at what happened, how serious the consequences were, and why this story concerns everyone who hosts projects in the cloud

What happened to Beget

On the night of November 2, 2026, Beget users began to massively report the inaccessibility of their resources. The first complaints appeared at about 03:00 Moscow time.

The problems were not limited to individual sites. Customers are faced with a number of problems:

Sites stopped loading or returned the 502 Bad Gateway error.
Virtual VPS/VDS servers are no longer available.
Personal accounts and hosting control panels were not opened.
There have been problems with DNS, a system that links domain names to IP addresses.
There were interruptions in the e-mail.

At 04:50 GMT, Beget officially confirmed a major incident. The company said that specialists are investigating and restoring infrastructure.

Later, representatives of the provider clarified that the problem affects all levels of architecture, and engineers are forced to manually restore the settings directly in the data centers.

This already indicated that we are not talking about the usual short-term failure of the web server.

The reason was called a massive cyber attack

Only in the afternoon, around 15:43 GMT, Beget revealed the stated cause of the incident.

According to the company, on the night of November 2, its infrastructure was subjected to a massive cyber attack that disrupted the operation of services.

The specific mechanism of the attack was not publicly disclosed.

The publication “Kommersant” reported anomalous activity in routing traffic associated with Beget networks. Sources of the publication also suggested possible interference in infrastructure configurations.

However, it is important to separate the facts and versions.

As of November 3, there is not enough public information to reliably state how the attackers gained access to the infrastructure, whether internal systems were compromised, or whether customer data was affected

The position confirmed at the moment is Beget’s statement about a massive cyber attack.

How massive was the failure

Beget is one of the largest players in the Russian hosting market.

According to statistics for October 2026, the company’s infrastructure hosted more than 334 thousand active sites in the domain zones .ru, .рф and .su.

This is not to say that all 334,000 websites have stopped working at the same time. However, the scale of the infrastructure shows how many projects are potentially dependent on a single vendor.

Monitoring services recorded thousands of complaints from different regions of Russia. According to ComNews, 33 cities reported problems.

It wasn’t just small websites and personal projects that were affected.

Among the services that faced problems, mentioned:

Honest sign. The information portal of the marking system was not available. At the same time, the CRPT operator specified that the marking system itself and the participants’ personal offices continued to work normally.
BelkaCar. Car sharing users experienced problems when completing car rentals. The company offered alternative ways to shut down cars.
Tourist and regional services. Some websites of tour operators and government organizations have been reported unavailable.

Thus, a local incident at the infrastructure provider had consequences far beyond its immediate customer base.

Why a single failure can shut down thousands of independent projects

The main technical problem of such incidents is the dependence of several critical components on a single supplier.

Imagine a regular online store.

His server is hosted on VPS Beget. The domain is served by Beget DNS servers. There are also mailboxes, backups and control panel.

At first glance, it is convenient: all services in one place, one payment and one technical support.

But in case of a serious accident, several seemingly independent systems can stop working at the same time.

Even if the server itself continues to work, the site may not be available due to a DNS failure.

DNS is required by the browser to determine which IP address to access the site. If the relevant DNS servers are not available, new address requests may result in an error.

And if the control panel is not available at the same time, the project owner may lose the ability to quickly change the configuration.

A single point of failure is a situation in which a single vendor problem affects several critical components of a project.

At the same time, transferring the DNS to another provider during an accident does not guarantee instant recovery: access to domain management, correct backup configuration and time to update DNS data are required.

What Happens to Customer Data

One of the most important issues is the status of backup copies and the ability to restore information.

In a statement, Beget said file backups of the vast majority of shared hosting and cloud infrastructure resources are available.

However, recovering large amounts of data will take a long time.

At the time of the announcement, the company has already managed to restore dedicated servers that are not administered by Beget.

Recovery of NS servers and the mail system was a priority.

The exact timing of the full return of all services to normal work, the provider did not name.

Importantly, the availability of file backups does not mean that all databases and the status of each project are safe.

Until the company publishes a detailed technical report, it is premature to conclude the full extent of the damage.

Beget announces force majeure

Together with the message about the cyber attack, the company sent customers an official notification of the circumstances that have signs of force majeure.

The document mentions paragraph 3 of article 401 of the Civil code of the Russian Federation.

For customers, this may be relevant when considering compensation claims for unavailability of services.

However, the statement of the provider about force majeure does not mean an automatic release from liability. The legal assessment depends on the terms of the contract, the nature of the incident and the specific circumstances.

At the same time, the usual compensation for the cost of hosting during downtime can be much less than the real business losses.

If an online store does not accept orders, the problem is no longer measured by the cost of a few hours of renting a server, but by lost sales and disrupted business processes.

What should developers do after this story

The Beget case is a reason to rethink the architecture of your own projects, regardless of what hosting is used.

It’s not that every small site needs to be moved to multiple clouds. For most projects, this architecture will be redundant.

But a few basic measures can significantly reduce the consequences of such accidents.

1. Keep backup copies separately

If the server and all its backups are located at the same provider, a large-scale incident can make both the working project and its backups unavailable at the same time.

The optimal minimum is automatic backup of files and databases to external storage, independent of the main infrastructure.

It is equally important to regularly check whether the project can be restored from these copies.

2. Consider an independent DNS

For mission-critical projects, it is worth considering placing DNS with an independent provider.

This will not protect the server itself from failure, but it can make it easier to switch the domain to a pre-prepared backup site.

The main thing is to set up and test such a scheme before the accident, rather than trying to create it at the time of mass failure.

3. Set up external monitoring

Checking server availability from inside the same infrastructure does not always detect problems that are noticeable to real users.

External monitoring should check the availability of the site, APIs and basic user scripts from an independent network.

Ideally, notifications should come through a channel independent of the faulty server or its mail.

4. Prepare a recovery plan

It is useful for the developer to answer a few questions in advance:

Where are the current backups located?
How long will it take to deploy a project on a new server?
How much data is allowed to be lost during recovery?
Who has access to the domain, DNS and backup storage?
Is it possible to restore the project without the control panel of the main provider?

In infrastructure practice, RTO and RPO indicators are used for this.

*RTO is the allowable recovery time.

*RPO is the allowable amount of data loss expressed over time.

For example, if a database is backed up once a day, you could potentially lose changes over a period of up to 24 hours.

For a personal blog, this may be acceptable. For a financial service or online store is already a serious problem.

And here is vibcoding and AI development

Today, creating and deploying a project has become much easier.

AI agents help write an application, prepare a Docker configuration, connect a database and configure a depot.

But the speed of product creation does not guarantee the reliability of the infrastructure.

In one evening, you can assemble a working service that will perfectly pass tests and serve users, but will completely stop if one VPS fails.

It’s especially easy to miss recovery issues when most of the infrastructure is set up by an AI agent.

Therefore, when working with such tools, it is useful to set a separate task for auditing fault tolerance.

For example:

Analyze the infrastructure of my project. Find single points of failure, check backup strategy, DNS dependency, database and external services. Offer a minimal recovery plan after the hosting provider is completely unavailable. Do not change the production configuration without my confirmation.

Such analysis is not a substitute for real-world testing, but it helps to detect architectural risks that are easily overlooked during rapid development.

Should I leave Beget

A large-scale accident is a serious reason for analysis, but in itself it does not mean that all customers need to immediately change the provider.

Cyberattacks and major infrastructure failures can affect any vendor, including international cloud platforms.

When evaluating Beget post-recovery, it will be important to look not only at the length of downtime, but also at the company’s further actions:

How detailed will be the technical cause of the incident.
What measures will be taken to prevent recurrence.
Have you managed to save and restore customer data.
How emergency recovery procedures will change.
How compensation claims will be considered.

Answers to these questions will allow you to objectively assess the reliability of the provider.

Main conclusion

The history of Beget shows how much the modern Internet depends on infrastructure, which usually remains invisible.

For the user, a website is a page in a browser. For the developer – application, server, database, DNS, storage system and many other components.

When several of them depend on the same infrastructure, the consequences of failure can be much more serious than an ordinary application error.

The reliability of a project is determined not only by how well it performs under normal conditions, but also by how quickly it can be restored when something goes wrong

This is what every developer should think about, regardless of whether they write code themselves or create products with AI.