Beget lost its cloud to an attack on its control layer: what is confirmed, what is not, and what to change

In the night of November 1–2, 2026, Beget, one of Russia's large hosting providers, went down: sites, the control panel, DNS, mail and virtual servers. Two days later the company said the cause was a deliberate attack that wiped customer data in its cloud. This piece sets out what is confirmed, what is not, and what any company that relies on a provider or runs its own servers should take from it.

What happened, by the numbers we can source

Timeline

What Beget itself says

• Access and wiping. The attackers gained "access to the control layer of the whole architecture" and then launched "zeroing scripts" (our translation of Beget's Russian wording) (post 573).
• What was lost. Cloud data for VPS, S3 and Kubernetes. Binary (disk-image) backups of VPS are "completely lost". CDN and IP settings were also lost, according to secondary reports of the same statement.
• What survived. File backups of all hosting and cloud infrastructure, according to Beget. They cannot be handed back until more than 1,000 servers are checked by hand for hidden weaknesses and malicious scripts. A file backup is not a bootable server: restoring a VPS from files is slower than from a disk image.
• Customer data. On servers that hold customer data, Beget says it saw no attempts to download or change the data. This is preliminary and unverified. It recommends changing all passwords, access keys and other credentials.
• Legal side. Beget notified customers that the situation shows signs of force majeure under Russian civil law. We found no announced compensation as of Nov 4.

What is not known

• How the attackers got in. Beget has not said, citing the investigation. Nobody has claimed the attack.
• Whether it was a software vulnerability, stolen credentials or something else. Any answer here is a guess. vc.ru reports that Beget representatives rejected a link to the PHP vulnerabilities disclosed on October 21–22 (covered in our PHP2Shell guide); we have only that secondhand statement.
• Whether AI played any role in this attack. We found no source that says so. One outlet's claim of AI involvement was unsubstantiated in the reporting we read, and we do not repeat it.
• How much data is permanently lost. Kommersant writes that full server backups were destroyed. Beget distinguishes between disk-image backups (lost) and file backups (kept). We follow Beget's wording.
• Whether data was copied out. Beget says it saw no download attempts. That is not the same as a confirmed absence.

Why this can happen to any company

Strip away the details Beget has not shared and the confirmed shape is simple: one management layer that could act on everything. That is the normal design of a cloud, a hosting platform or a company's own virtualization stack, and it is also a single point of failure. If the same layer can delete the servers, the storage and the backups, then whoever holds it holds all three.

The scale matters less than the pattern. A small company usually has the same shape in miniature: one admin account for the hypervisor or cloud console, backups written by the same credentials that run production, and a list of software that nobody has fully written down.

What to do

1. Keep a backup the production admin cannot delete. Immutable (write-once) storage or an offline copy, held by a different account, ideally at a different provider. Test a full restore, not just that files exist.
2. Split access. Separate roles for running servers, for managing backups and for the control layer itself; require strong authentication on every account that can reach the control layer, and review who can.
3. Know what you run. Keep a current list of software and versions on every internet-facing host. You cannot patch what you have not listed. My Stack lets you track products and get flagged when a CVE affecting them moves toward exploitation.
4. Patch by exposure, not by calendar. Internet-facing systems first; check the live exploitation radar and the risk trends to see what attackers are using now.
5. Assume a provider can fail. If your sites, DNS or mail live with one provider, know how long you can go without them and keep a copy of your data elsewhere.
6. After a provider incident, rotate credentials and keys stored on affected servers, as Beget itself recommends.

The AI angle: what the numbers and the sources support

There is a strong claim going around that AI models now let anyone break into anyone. We cannot test that. What we can do is count: how many CVEs are published each year in our index, and what the sources say about AI-found vulnerabilities.

In 2025 the monthly count hovered around 4,000. In 2026 it has risen in almost every month (April dipped slightly), from 4,398 in January to 17,210 in October, nearly four times October 2025. The first nine months of 2026 already exceed the whole of 2025.

Our 2026 estimate, and how we got it

• Where we are: 94,122 published CVEs from January 1 to November 5, of which 92,329 were in January to October and 1,793 in the first days of November.
• Estimate, low: the average of August, September and October is 14,863 per month. Two more months at that pace add about 29,700, for roughly 122,000.
• Estimate, high: two more months at October's level (17,210) give roughly 127,000.
• Comparison: 2023, 2024 and 2025 together contain 119,541 CVEs in our index, so 2026 would land at about the same total as the previous three years combined. This is our estimate, not a forecast from any official body. Months can jump on days when one publisher releases thousands of records at once. Nobody can say what 2027 looks like.

Does this prove AI is the cause?

No, and it would be wrong to say so. We looked at one other explanation we can measure. Records from the Linux kernel CNA (the kernel team as its own CVE issuer) grew from 5,674 in 2025 to 8,241 in 2026, an increase of about 2,600 out of the roughly 44,700 added. So the kernel CNA explains a small part of the rise. Other factors that may matter and that we did not measure: more organisations issuing CVEs, more bug-bounty and plugin-ecosystem reporting, and changes in how the NVD backlog is processed. We cannot split the growth between those and AI-assisted discovery.

What the sources do say about AI and vulnerability discovery

• Anthropic, Oct 27, 2026: an internal research model found 62 CVEs in Chrome and a Linux kernel bug, CVE-2026-98432, with a proof of concept for root code execution. Each exploit still needed initial human prompting, and the findings went through coordinated disclosure (Anthropic).
• XBOW, Apr 2, 2026: the autonomous testing company says Microsoft credited it in the March 2026 Patch Tuesday for a critical RCE, CVE-2026-21536 (XBOW). That is a vendor's own account of a finding Microsoft acknowledged.
• Google's threat intelligence group (GTIG), Sep 8, 2026: attacks are moving from single prompts to agentic pipelines, and attackers are faster at turning published vulnerability details into working exploits. GTIG says it does "not yet" see fully autonomous attacks on real targets (GTIG report; we read it through a SecurityLab summary).
• Speed after disclosure: Amazon's honeypot saw PHP2Shell exploitation attempts four days before the patch, and AWS argues AI-assisted analysis is shortening the gap between a patch and a working exploit (AWS). We have no source saying PHP2Shell was found by AI; we use it as an example of how fast exploitation moves, not of AI discovery.
• Access to strong cyber capability is gated for some models. Anthropic describes a verification program that gives vetted security professionals reduced safety blocking. We found no source we could cite comparing how other vendors' models, open-weight or Chinese ones, are restricted, and we make no claims about them.
• What no source says: that AI was used against Beget.

Our conclusion: CVE volume is rising fast, AI-assisted discovery is documented and plausibly part of the reason, and the part we can prove is the pace. More flaws are published faster and exploitation follows publication quickly, so the list of what needs patching grows while the window to act shrinks. That is true whether or not AI touched the Beget attack. Kommersant's expert Filipp Kulin makes a similar argument and expects more such outages; Pavel Myasoedov of IT-Rezerv replies that building infrastructure to be unhackable would make hosting unaffordable for small and mid-sized businesses, and that large providers rely on redundancy and isolation (Kommersant). Both views point the same way: plan for failure instead of betting on prevention. The live picture is on the trends page.

Security is not a one-person job, and scanning is not optional

Nobody can hold the whole picture alone: the list of what you run, which of it is exposed, which of it has a fix waiting, and whether your backups would actually survive. Scanners do not replace judgement, but they do the continuous part that people cannot, and they will be run against you whether you run them or not. The practical move is to see your own perimeter before someone else does, and to repeat it regularly.

Data as of 2026-11-05live record →

Sources: Beget Telegram post 570, post 572, post 573, Beget status banner, Google GTIG, From prompting to autonomy, Anthropic research, Oct 27, 2026, XBOW, AWS Security Blog, CISA KEV catalog. Expert quotes and the 330,000-site figure: Kommersant, Nov 3 (original reporting). Early timeline times: vc.ru. Statements of Beget are our translation from Russian. CVE statistics: CVE Tools index, Nov 5, 2026.