Сбой Рунета 8 октября 2026 года: ИБ-компания Curator признала свою вину

8 октября 2026 года Рунет долгое время работал с серьёзными перебоями по всей стране. Многочисленные сайты не открывались, популярные сервисы переставали отвечать. Первое объяснение лежало на поверхности: в тот же день произошла атака БПЛА на дата-центр «Яндекса». Позже картина изменилась. Причиной оказалась ИБ-компания Curator. Она признала вину и утверждает, что проблему, сломавшую россиянам интернет, уже решила.

Хронология и версии

Сбой, затронувший сайты и сервисы по всей стране, почти неизбежно ищут в крупнейших точках инфраструктуры. Совпадение по времени с атакой на дата-центр «Яндекса» выглядело как готовое объяснение, и его приняли за основу. Но, судя по сообщениям, одно событие с другим напрямую не связано.

Что известно на данный момент:

• дата инцидента: 8 октября 2026 года;
• масштаб: по всей России, в течение длительного времени;
• симптомы: не открывались многочисленные сайты, не работали популярные сервисы;
• первая версия: последствия атаки БПЛА на дата-центр «Яндекса»;
• итоговая версия: виновата ИБ-компания Curator;
• статус: Curator признала вину и заявляет, что устранила проблему.

Две вещи в этой истории нужно держать раздельно. Атака на дата-центр действительно произошла, и это отдельный факт. Но массовую недоступность сервисов по стране она, по текущим данным, не объясняет.

Чего мы пока не знаем

Источник ограничивается самим фактом признания. Нет данных о механизме сбоя, о том, какие именно продукты или сервисы Curator оказались вовлечены, сколько часов длился инцидент и какие компании пострадали сильнее всех. Также не раскрыто, что именно сделала Curator для устранения проблемы и можно ли считать инцидент полностью закрытым.

Пока эти вопросы без ответа, любые выводы о технической природе сбоя были бы догадками. Редакция будет ждать официального разбора от самой компании, операторов и затронутых сервисов.

Один вывод всё же напрашивается. Если ошибка поставщика средств информационной безопасности смогла нарушить работу сайтов и сервисов в масштабах страны, значит, такие поставщики входят в цепочку критической зависимости. Об этом обычно вспоминают только после инцидента.

Что проверить командам

Для владельцев сервисов и ИТ-директоров этот эпизод повод провести короткий аудит, не дожидаясь подробностей.

• Составьте перечень внешних сервисов, которые стоят на пути трафика или влияют на доступность: защита, фильтрация, DNS, CDN, провайдеры сертификатов.
• Для каждого определите, что произойдёт при его отказе: сервис продолжит работать, деградирует или полностью остановится.
• Проверьте, есть ли резервный маршрут и кто принимает решение о переключении на него. Ночью и в выходной день это должен уметь сделать дежурный инженер.
• Настройте внешний мониторинг из нескольких сетей. Так вы быстро поймёте, проблема у вас, у провайдера или в масштабе всей страны.
• Заранее подготовьте шаблон коммуникации с клиентами. 8 октября первая версия причины оказалась неверной, и это показывает цену поспешных объяснений.

Полная картина появится после публикации технического разбора. Пока же понятно главное: сбой такого масштаба может начаться не с самой заметной аварии, а с ошибки в сервисе, о котором пользователи не знают.