У хостеров проблемы? Массовые взломы, утечки данных и экстренные обновления инфраструктуры

В октябре и начале ноября 2026 года российский рынок хостинга столкнулся сразу с несколькими серьезными инцидентами. Через уязвимости VMmanager 6 были атакованы десятки провайдеров, у FirstVDS злоумышленники получили возможность читать файлы клиентских серверов, а 2 ноября Beget подвергся разрушительной кибератаке. Одновременно появились сообщения о защитных ограничениях, технических работах и проблемах с обслуживанием клиентов у других хостинговых компаний. Разбираемся, что произошло, как связаны эти события и какие угрозы они создают для бизнеса.

Материал подготовлен по состоянию на 5 ноября 2026 года на основании официальных сообщений провайдеров, отчетов разработчиков программного обеспечения и публикаций отраслевых СМИ.

Одна уязвимость — десятки провайдеров

Главным событием октября стала масштабная атака на VMmanager 6 — платформу управления виртуальными серверами компании ISPsystem, входящей в «Группу Астра».

В официальном расследовании от 27 октября разработчик подтвердил, что скоординированная многоэтапная атака затронула инфраструктуру нескольких десятков хостинг-провайдеров.

Первые следы проникновения у некоторых клиентов были обнаружены 12 октября. Уже 14 октября в ISPsystem поступило обращение о подозрительной активности, а 17 октября произошла новая волна атак.

Злоумышленники использовали несколько уязвимостей, включая ранее неизвестную уязвимость класса HTTP Request Smuggling — метод, позволяющий обойти определенные механизмы обработки и проверки HTTP-запросов.

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

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

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

С подробной хронологией можно ознакомиться не только в отчете ISPsystem, но и в технической публикации разработчика на Хабре.

FirstVDS: злоумышленники читали файлы клиентских серверов

Одним из наиболее серьезных подтвержденных случаев стал взлом FirstVDS.

18 октября компания опубликовала первое предупреждение, а 27 октября представила подробный технический отчет.

Согласно расследованию, злоумышленник получил административный доступ к VMmanager 6 и запустил специализированный сборщик данных на физических узлах виртуализации.

Этот инструмент подключал диски клиентских виртуальных машин в режиме чтения и копировал выбранные файлы.

В перечень потенциально скомпрометированной информации входили:

• SSH-ключи, системные пароли и учетные данные администраторов;
• конфигурационные файлы сайтов и приложений, включая .env;
• логины и пароли баз данных;
• токены GitHub, GitLab и других сервисов;
• ключи доступа к облачным платформам;
• API-ключи сторонних приложений, включая ИИ-сервисы;
• криптокошельки и приватные ключи;
• история команд и другие конфиденциальные файлы.

Особенно опасен сам механизм атаки: сборщик работал на уровне гипервизора, а не внутри клиентской операционной системы.

Поэтому отсутствие подозрительных SSH-подключений и неизвестных процессов на виртуальном сервере не исключает утечки информации.

Масштаб компрометации

В опубликованном отчете FirstVDS сообщает об обнаружении архивов сборщика на 457 физических узлах виртуализации.

Общий объем найденных архивов составил 117,24 ГиБ.

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

Для оценки рисков провайдер принял консервативный подход и рекомендовал владельцам затронутых VPS исходить из возможной компрометации хранившихся на них данных.

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

Последствия для обслуживания клиентов

Инцидент затронул и повседневную работу хостинга.

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

19–20 октября новые серверы временно не создавались из-за нарушения работы модуля выдачи IP-адресов.

Позже компания сообщила об увеличении времени обработки обращений и переносе функций управления серверами из VMmanager в личный кабинет.

3 ноября FirstVDS опубликовал подробные ответы на вопросы о проблемах с управлением серверами и отдельно объявил программу компенсаций.

Это показывает, что даже после устранения первоначальной уязвимости восстановление обычных процессов обслуживания может занимать значительное время.

Какие еще провайдеры пострадали

По мере развития расследования стало ясно, что FirstVDS был далеко не единственной компанией, затронутой атакой.

В публикации РБК от 20 октября упоминаются FirstVDS, ForestsNet Cloud, MHost, HSH Network и YaColo.

Собственные отчеты о связанных с VMmanager инцидентах также представили ProfitServer и Senko Digital.

ForestsNet Cloud

Компания сообщила о взломе 18 октября.

По результатам собственного расследования у злоумышленников оказалась база данных управляющей панели, содержащая IP-адреса серверов, адреса электронной почты, определенные root-пароли и пароли VNC.

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

ForestsNet временно закрывал панель управления, устанавливал исправления и менял служебные учетные данные.

ProfitServer

ProfitServer также официально подтвердил, что пострадал от эксплуатации уязвимостей VMmanager 6.

Компания сообщила о проведении собственного расследования, установке обновлений и необходимости замены потенциально скомпрометированных учетных данных.

Отдельное внимание в публикации уделено недостатку технической информации об атаке на ранних этапах.

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

Senko Digital

Особенно показателен технический отчет Senko Digital.

По данным компании, 12 октября злоумышленник проник в систему VMmanager и создал административные API-токены.

Однако раннее обнаружение активности позволило предотвратить дальнейшее развитие атаки.

В ходе расследования компания не обнаружила признаков доступа к виртуальным машинам клиентов или копирования их данных.

Этот случай демонстрирует важность оперативного мониторинга: одна и та же уязвимость может приводить к совершенно разным последствиям в зависимости от скорости обнаружения и реагирования.

MHost, HSH Network и YaColo

Эти компании также фигурируют в расследовании РБК о массовой атаке.

Однако доступной публичной информации недостаточно, чтобы утверждать одинаковый масштаб компрометации клиентских данных у всех трех провайдеров.

Факт упоминания компании среди затронутых не означает, что злоумышленники получили доступ ко всем размещенным у нее виртуальным серверам.

Eurobyte

Еще один участник отрасли — Eurobyte.

В сообщении от 19 октября, опубликованном в том числе через отраслевой агрегатор Hosting Kitchen, компания рассказала о попытке несанкционированного доступа к VMmanager 6.

Провайдер ограничил внешний доступ к управляющей панели и начал проверку возможных последствий.

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

Как реагировал разработчик VMmanager

Компания ISPsystem официально подтвердила инцидент 20 октября.

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

19 октября была установлена возможность эксплуатации уязвимости HTTP Request Smuggling.

23 октября вышли дополнительные обновления безопасности для нескольких продуктов экосистемы ISPsystem, включая VMmanager, DCImanager, BILLmanager и DNSmanager.

В расследовании также сообщается о привлечении специалистов по информационной безопасности и применении инструмента Kaspersky Virus Removal Tool для поиска оставшихся вредоносных компонентов.

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

По информации ISPsystem, после установки исправлений от 19 октября новых случаев компрометации обновленных инфраструктур не фиксировалось.

При этом завершение атаки и полная очистка ранее скомпрометированных систем — разные задачи: устранение уязвимости не удаляет автоматически ранее созданные злоумышленником средства сохранения доступа.

2 ноября: разрушительная атака на Beget

На фоне октябрьских событий произошел новый масштабный инцидент.

В ночь с 1 на 2 ноября атаке подверглась инфраструктура Beget.

В отличие от многих случаев компрометации VMmanager, целью этой атаки стало не только получение доступа, но и уничтожение данных.

Согласно официальной хронологии Beget:

• около 02:00 злоумышленники получили доступ к управляющим серверам;
• около 02:30 было запущено вредоносное ПО, предназначенное для удаления данных;
• в 02:40 компания обнаружила признаки взлома;
• в течение следующих суток началось поэтапное восстановление инфраструктуры.

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

2 ноября компания восстановила работу NS-серверов.

3 ноября началось восстановление серверов виртуального хостинга, а также проверка хранилищ резервных копий.

4 ноября были запущены первые сайты на восстановленной инфраструктуре.

Хронология восстановительных работ опубликована непосредственно на официальном сайте Beget.

Если в случае FirstVDS ключевым установленным риском была утечка секретов, то в случае Beget атака также угрожала целостности и доступности клиентских данных.

Оба сценария могут приводить к существенным финансовым и операционным потерям бизнеса, однако требуют разных процедур реагирования.

Проблемы у других провайдеров: совпадение или реакция на угрозы?

На фоне масштабных инцидентов стали появляться и другие сообщения.

REG.RU

22 октября пользователи крупнейшего российского регистратора и хостинг-провайдера REG.RU столкнулись с ошибкой 403 при попытке загрузить файлы через панель управления. В комментарии «Коммерсантъ» компания официально пояснила, что временно ограничила часть функций загрузки файлов в качестве превентивной защитной меры после появления сведений о критических уязвимостях в PHP — еще до выхода официальных патчей.

При этом подтвержденной публичной информации о взломе REG.RU через VMmanager в рамках рассматриваемой кампании не обнаружено. Было бы некорректно делать вывод о компрометации инфраструктуры компании только на основании превентивных защитных ограничений.

Selectel

3 ноября — на следующий день после атаки на Beget — облачный провайдер Selectel зафиксировал крупный сетевой инцидент (Major incident) в пуле ru-7, продлившийся около 14 часов. Сбой затронул облачные серверы, балансировщики нагрузки, кластеры Managed Kubernetes, управляемые базы данных и «Облако для 1С». Кроме того, ранее, 28 октября, в пуле ru-7b фиксировались сбои в работе сетевых дисков.

Согласно статус-панели провайдера, проблемы носили сетевой и инфраструктурный характер (потребовалась стабилизация контроллеров виртуальной сети); никаких признаков того, что сбой в Selectel был вызван кибератакой или связан с уязвимостями VMmanager, нет.

Yandex Cloud и Curator (Qrator Labs)

Еще одна заметная волна сбоев в Рунете произошла 8–11 октября по не связанным с VMmanager причинам. Во-первых, ряд облачных сервисов и корпоративных платформ (например, система КЭДО Nopaper) столкнулись с длительной недоступностью из-за физических инцидентов и отключения электропитания в дата-центрах Yandex Cloud.

Во-вторых, 8 октября произошел сбой в сети провайдера защиты от DDoS-атак Curator, из-за которого временно перестали открываться сайты крупнейших СМИ и компаний. Как официально подтвердили в пресс-службе компании изданию «Коммерсантъ» и на Хабре, причиной стала внутренняя ошибка конфигурации при проведении технических работ, которая была устранена в течение 40 минут.

Почему нельзя объединять все эти события

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

Однако эти события необходимо разделять.

Октябрьская атака VMmanager — документально подтвержденная скоординированная кампания.

Ноябрьский инцидент Beget — отдельно подтвержденная разрушительная кибератака.

Защитные ограничения в REG.RU, сетевой сбой в пуле ru-7 у Selectel, авария при техработах у Curator и инциденты в дата-центрах Yandex Cloud имеют собственные документально подтвержденные причины и сами по себе не связаны с компрометацией VMmanager или атакой на Beget.

Вместе с тем масштабные события могут стимулировать других провайдеров ускорять обновления, пересматривать настройки безопасности и проверять резервное копирование.

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

Дополнительный фактор: критические уязвимости PHP

Октябрь оказался сложным для хостингов не только из-за VMmanager.

20 октября стала известна информация о критических уязвимостях PHP, получивших название PHP2Shell.

Они затрагивали широко распространенные серверные компоненты и создавали угрозу удаленного выполнения вредоносного кода.

Уже 21 октября РБК опубликовал материал об угрозах для российских сайтов.

23 октября FirstVDS сообщил о выпуске исправлений, а 27 октября опубликовал новые сведения о возможных способах эксплуатации.

Таким образом, в течение нескольких дней хостинг-провайдерам пришлось одновременно решать задачи ликвидации последствий атак на инфраструктуру виртуализации и устранения критических уязвимостей распространенного серверного ПО.

Это могло создавать дополнительную нагрузку на инженерные команды и техническую поддержку.

Использовали ли злоумышленники искусственный интеллект?

В расследовании ISPsystem содержится еще один интересный вывод: по оценке разработчика, атака велась с применением специализированных ИИ-инструментов.

Эту версию также освещал РБК в материале от 27 октября.

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

Однако важно учитывать, что применение ИИ в конкретной атаке остается выводом расследования ISPsystem. Независимого подтверждения точной роли и автономности использованных инструментов в опубликованных материалах нет.

Тем не менее событие показывает, насколько опасным становится сочетание автоматизированного поиска уязвимостей и широко используемых инфраструктурных платформ.

Чем это угрожает бизнесу

Для обычной компании последствия подобных инцидентов могут оказаться значительно шире временной недоступности сайта.

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

Например, сервер интернет-магазина может содержать:

• данные подключения к базе клиентов;
• интеграцию с облачной или коробочной CRM;
• ключи платежных и логистических сервисов;
• токены Telegram-ботов;
• доступы к почтовым сервисам;
• ключи автоматизации и внешних API.

Компрометация одного сервера потенциально создает угрозу для всех этих систем.

Причем последствия могут проявиться не сразу.

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

Поэтому после подтвержденной компрометации недостаточно проверить только сайт и сменить пароль администратора CMS.

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

Какие меры стоит принять владельцам сайтов

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

Независимое резервное копирование. Резервные копии следует хранить вне основной инфраструктуры, с отдельными учетными данными и регулярной проверкой восстановления.

Разделение проектов. Критически важные системы желательно изолировать друг от друга, чтобы компрометация одного сервера не открывала доступ ко всем бизнес-процессам.

Контроль секретов. Пароли, SSH-ключи, API-токены и доступы к CRM должны учитываться и регулярно проверяться. При подтвержденном риске компрометации их необходимо отзывать и перевыпускать.

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

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

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

Итог: рынок получил серьезное предупреждение

За несколько недель российская хостинг-индустрия столкнулась с двумя крупными подтвержденными событиями: многоэтапной атакой на инфраструктуры провайдеров через VMmanager 6 и разрушительной кибератакой на Beget.

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

Дополнительные уязвимости PHP усилили нагрузку на отрасль и необходимость оперативного применения обновлений безопасности.

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

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

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

Источники и дополнительные материалы

Ниже приведены прямые ссылки на опубликованные материалы, использованные для анализа. Сначала представлены документы разработчиков и провайдеров, затем отраслевые публикации и технические справочные материалы.

Официальные расследования и сообщения

1. ISPsystem, 27.10.2026. Атака на VMmanager 6 Hosting — разбор инцидента и хронология расследования. Основной технический первоисточник: масштаб атаки, механизм эксплуатации, хронология и исправления.
2. ISPsystem, 20.10.2026. Об инциденте, связанном с уязвимостью VMmanager 6. Первое официальное подтверждение и рекомендации по изоляции инфраструктуры.
3. ISPsystem, Хабр, октябрь 2026. Атака на VMmanager 6 — хронология инцидента и разбор уязвимостей. Техническое объяснение атаки, защитных мер и результатов проверки исправлений.
4. FirstVDS, 18.10.2026. Уязвимость VMmanager: срочно смените доступы. Первое уведомление о компрометации, инструкции клиентам и последующие обновления.
5. FirstVDS, 27.10.2026. Постмортем — атака на FirstVDS 17.10.2026. Подробное расследование, данные о 457 физических узлах и найденных архивах.
6. FirstVDS, 03.11.2026. FAQ: закрытие VMmanager, уязвимости PHP и проблемы с доступом. Объяснение технических и организационных последствий.
7. FirstVDS, 03.11.2026. Компенсации после инцидента с VMmanager. Условия компенсаций клиентам.
8. FirstVDS, 29.10.2026. Октябрь — уязвимости в VMmanager и PHP. Дайджест защитных мероприятий и материалов по безопасности.
9. FirstVDS, 23.10.2026. В PHP выпустили патчи для PHP2Shell. Сведения о критических уязвимостях и обновлениях.
10. FirstVDS, 27.10.2026. PHP2Shell: появился эксплойт с обходом ASLR и найдена новая уязвимость. Дополнительный технический анализ угроз PHP.
11. Beget, обновление 04.11.2026. Официальная хронология кибератаки и восстановительных работ. Основной первоисточник по событиям 2–4 ноября.
12. ForestsNet Cloud, 18.10.2026. Взлом хостингов на VMmanager 6: что утекло, что мы сделали и что сделать вам. Собственный отчет о компрометации панели.
13. ProfitServer, октябрь 2026. Инцидент безопасности VMmanager 6: что произошло и что делать. Официальная позиция пострадавшего провайдера.
14. Senko Digital, октябрь 2026. VMmanager Security Incident — Post-Mortem. Техническое расследование с хронологией действий злоумышленника.

СМИ и отраслевые публикации

15. РБК, 20.10.2026. Хостинг-провайдеры предупредили о взломе системы управления облаками. Названия затронутых компаний и комментарии экспертов.
16. РБК, 21.10.2026. «Астре» привили вредоносное ПО. Расширенная газетная публикация о последствиях атаки.
17. РБК, 27.10.2026. В «Астре» обвинили ИИ во взломе хостинг-провайдеров. Разбор позиции разработчика и версии использования ИИ.
18. РБК, 27.10.2026. В краже данных обнаружился искусственный след. Газетная публикация о расследовании и автоматизации атаки.
19. РБК Инвестиции, 20.10.2026. Акции «Группы Астра» упали на фоне сообщения о хакерском взломе. Дополнительный материал о реакции рынка.
20. РБК, 21.10.2026. Эксперты MWS AI и Positive Technologies оценили угрозу российским сайтам из-за уязвимостей PHP. Контекст второй волны рисков безопасности.
21. Hosting Kitchen, октябрь 2026. Отраслевые сообщения, включая уведомление Eurobyte о попытке доступа к VMmanager. Агрегированная публикация; не является самостоятельным техническим расследованием.
22. Коммерсантъ, 22.10.2026. Крупнейший российский хостинг «Рег.ру» временно ограничил загрузку файлов. Официальный комментарий компании о превентивных защитных мерах из-за уязвимостей в PHP.
23. Коммерсантъ, 08.10.2026. Сбой в Curator из-за ошибки персонала затронул доступ к СМИ. Подтверждение причин сетевого сбоя при технических работах (также заявление компании на Хабре).

Технические справочные материалы

24. PortSwigger Web Security Academy. HTTP Request Smuggling — вариант CL.0. Объяснение класса уязвимостей, применимого к техническому разбору FirstVDS.

Дополнительные страницы и статус-панели провайдеров

Следующие страницы содержат отчеты о технических сбоях и статусе инфраструктуры, не связанных с компрометацией через VMmanager:

25. Beget. Официальный сайт и обновления о восстановлении инфраструктуры.
26. Selectel, 03.11.2026. Major incident: Network issues in ru-7 и отчет по сетевым дискам в ru-7b от 28.10.2026 на официальной статус-панели.
27. Nopaper, октябрь 2026. Сбой 11–12 октября: причины, восстановление и меры по защите — разбор последствий отключения дата-центров Yandex Cloud.

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