Habr•October 12, 2026•🇷🇺Translated from Russian

Yandex Cloud Cascade Failure October 2026 Exposes Multi-AZ Limits and Capacity Exhaustion Risks

In October 2026, Yandex Cloud experienced a major cascade failure spanning data centers in Sasovo, Kaluga, and Vladimir, demonstrating the physical limits of Multi-AZ resilience when multiple zones suffer simultaneous outages.

The events began on 8 October at 01:31 MSK in zone ru-central1-b (incident 2092) with power disruptions. By 15:19 MSK, Yandex Cloud confirmed a fire caused by a drone attack that completely halted the Sasovo facility. Clients were advised to migrate workloads, yet new virtual machines, Managed Kubernetes clusters, and databases could not be created in remaining zones due to emerging capacity constraints.

At 15:30 MSK the same day, an unrelated configuration error during planned maintenance in the Curator DDoS protection service degraded access for 34 minutes to major Russian media and fintech platforms including RBK, Kommersant, Vedomosti, Interfax, T-Bank, and Avito.

On 9 October, damage was reported at the Kaluga site. Yandex Cloud arranged emergency resource placement with external providers Selectel, K2Cloud, and VK Cloud. Control Plane components for regional Kubernetes clusters could only be moved out of the affected zone after approximately 36 hours.

By 10 October, quota allocation shifted to fully manual mode, freezing automatic scaling and giving priority to critical workloads. On 11 October at 04:00 MSK, power failures struck zone ru-central1-a (incident 2136) in Vladimir, leading to another full site shutdown and an official warning that remaining capacity no longer guaranteed availability.

At 07:13 MSK on 11 October, compute resources remained available only in zones ru-central1-d and ru-central1-e. Many database clusters switched to read-only or became unavailable, while object storage allowed reads but not writes. Several Kubernetes clusters lost manageability because their control planes resided in failed zones.

Services such as Yandex Go, Yandex Eda, Yandex Pay, and Yandex 360 were impacted, along with the state VetIS system. The SaaS platform Salebot lost access to client projects and weekly backups, forcing a rollback to 4 October data and requiring more than 24 hours to rebuild indexes after restoring only six of 40 servers.

The outage illustrated that Multi-AZ architectures fail when surviving zones lack sufficient physical capacity, a condition known as Capacity Exhaustion. Additional risks included Control Plane dependency, manual quota limits blocking automated recovery, and simultaneous demand from multiple customers overwhelming alternative providers.

To mitigate such risks, the analysis recommends separating ingress buffers from primary backends. A lightweight FastAPI service deployed on an independent VDS can accept webhooks, validate tokens via constant-time comparison, and durably append events to a local JSONL queue using fsync before returning 200 OK responses.

Related articles

Habr•Other

Passkeys in Production: How One Developer Replaced Passwords with Face ID in Three Days Using FastAPI and Next.js

Yaroslav Morozov details a complete production implementation of Passkeys based on the WebAuthn standard and FIDO2 protocols. The article explains why Passkeys eliminate phishing and database breach risks compared to traditional passwords while providing biometric login via Face ID or Touch ID. It covers database schema design with PostgreSQL tables for credentials and challenges, SQLAlchemy models, and minimal dependencies including py-webauthn on the backend and SimpleWebAuthn on the frontend. Full working code for registration and authentication flows is provided, showing how Passkeys integrate with existing JWT token systems without major refactoring. The guide includes environment configuration, error handling, challenge management with five-minute TTL, and security considerations such as sign count verification to detect cloned keys.

Habr•Other

Yandex Disk Files Become Partially Inaccessible After Sasovo Data Center Incident

A detailed user report reveals that approximately one percent of files stored on Yandex Disk are currently unavailable for download following reported incidents at the Sasovo data center. The problems manifest in three distinct states: missing thumbnails with downloadable originals, visible thumbnails with inaccessible originals returning 504 Gateway Time-out errors, and cases where both thumbnails and originals fail to load. Technical analysis using curl requests traced the failures to specific storage nodes such as s418klg.storage.yandex.net, indicating that some data shards may reside in affected infrastructure while others remain operational. Yandex support requested original files for diagnosis but closed the ticket without providing an official explanation or confirming data integrity. The author emphasizes that the issue affects files across both the Photos and Files sections and recommends maintaining offline backups due to the lack of guaranteed availability during data center failures.

AntiMalware•Other

Keurig K-Supreme Smart Coffee Maker Generates Nearly 1 TB of Outbound Traffic in Ten Days

A Keurig K-Supreme Smart coffee maker unexpectedly produced around 1008 GB of outgoing traffic over ten days, overwhelming a home UniFi access point while generating only 9.94 GB of inbound data. The device had been placed on a separate network segment, yet the traffic remained largely internal to the home LAN rather than traversing the internet connection. The anomaly was discovered by user Nomad while assisting family members with network maintenance through the UniFi dashboard. After the coffee maker was powered off, the issue could not be reproduced in subsequent testing, and no packet captures were available to determine the content or root cause of the traffic. The model requires internet connectivity for remote control, scheduling, capsule recognition, and automatic reordering of coffee supplies. No similar incidents have been reported by other users, and the manufacturer has not issued any statement regarding the event.

Habr•Other

Hash Functions Part 1: Core Properties, Security Requirements and Practical Applications

The article provides a detailed introduction to hash functions, explaining how they map arbitrary-length input to fixed-length output while satisfying three fundamental security properties. It covers preimage resistance, second preimage resistance, and collision resistance, along with the avalanche effect that makes even minor input changes produce unrecognizable output. The text explains why a 256-bit digest is required to achieve 128-bit collision resistance, referencing the birthday paradox and its implications for MD5 and SHA-1. Practical guidance includes using OpenSSL for hashing, applying hashes in commitment schemes, enforcing subresource integrity on web pages, and securely storing passwords with Argon2 and bcrypt. The post emphasizes that hash functions alone do not guarantee integrity without proper transmission of the digest and announces a follow-up on SHA-2 and SHA-3 internals.