Safeguard
Cloud Security•

Yandex Cloud puts platform in emergency mode after data center strikes

Yandex reported drone attacks on three data centers between 8 and 11 Oct 2026 and told customers to use other disaster recovery plans. A physical outage case for dependency planning.

Safeguard Security Team
3 min read

Between 8 and 11 October 2026, Yandex said drone attacks damaged three of its data centers. Two stopped operating completely and one was degraded. Yandex told customers its platform was in "emergency" mode and recommended alternative disaster recovery plans.

This is a physical event, not a software fault, and the facts below come from BleepingComputer's 12 October report of Yandex's statements. We did not load Yandex's status page directly.

What happened

  • Sasovo: hit 8 October, stopped operating completely.
  • Kaluga: hit 9 October, operations degraded.
  • Vladimir: attacked 11 October, stopped operating completely.

Yandex reported no injuries and said it could not give a reliable restoration timeline. The most recent service status cited: console, API, IAM, container registry, databases, S3 storage and Kubernetes available with some issues, compute, AI Studio and security services partially available, and Monium offline.

Confirmed, reported, unknown

  • Confirmed by Yandex (as reported): the three sites, the dates, emergency mode, no injuries, no restoration estimate.
  • Reported: BleepingComputer cites a BBC report that the attacks are believed to have been carried out by Ukrainian forces. Yandex has not confirmed attribution.
  • Unknown: whether any customer data was irreversibly lost. One customer reported missing thumbnails and unavailable files in Yandex Disk backups, with HTTP 302, 504 and 500 errors, and Yandex has not addressed data loss in its updates.

What to do now

  1. Find out which of your providers have data centers in or near conflict zones, and which regions your workloads actually use.
  2. Check that backups live in a different provider or at least a different region than the data they protect.
  3. Test a restore, not just a backup job.
  4. Write down who decides to fail over and what the trigger is.

How this could have been avoided

Customers could not prevent a strike, but they could limit the damage. Cross provider backups, a tested restore path and a documented failover trigger turn a provider emergency into a planned recovery. A vendor risk review that asks where a supplier's sites are is the cheapest way to start.

Click through it at your own pace, or open it full screen.

Quick check

Has Yandex confirmed who carried out the attacks?

No. Attribution in the report comes from a BBC report cited by BleepingComputer, not from Yandex.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.