Назад в блог/Взлом VMmanager 6 в октябре 2026: хроника, что украли с VPS и что делать клиентам
Команда AZERTA•~5 мин чтения

Взлом VMmanager 6 в октябре 2026: хроника, что украли с VPS и что делать клиентам

Разбор взлома VMmanager 6 (ISPsystem) в октябре 2026 года: хроника атаки на FirstVDS и других провайдеров, что украли с дисков VPS, почему внутри серверов нет следов взлома, чек-лист действий для клиентов и почему AZERTA использует собственную панель управления.

В октябре 2026 года российский хостинг пережил второй за год громкий инцидент безопасности: через уязвимость в платформе виртуализации VMmanager 6 от ISPsystem (входит в «Группу Астра») злоумышленники атаковали сразу несколько хостинг-провайдеров и скопировали данные с дисков клиентских виртуальных серверов. Пострадали FirstVDS, ForestsNet Cloud, MHost, HSH Network, YaColo и другие операторы; Gcore в превентивном порядке закрыл доступ к панелям VMmanager 6 и DCImanager 6.

Разбираем хронику взлома VMmanager 6, что именно украли, почему атака не оставила следов внутри серверов и что сейчас нужно сделать каждому владельцу VPS. Все факты — со ссылками на источники.

Хроника взлома VMmanager 6

  • 11–16 октября 2026 — предварительная фаза: злоумышленники через уязвимость в VMmanager 6 заражают панели управления хостинг-провайдеров и закрепляются в инфраструктуре. Уязвимость эксплуатировалась как 0-day — до публичного раскрытия и выхода исправлений.
  • Ночь с 16 на 17 октября — активная фаза: атакующие получают доступ к базам данных управляющих панелей, где хранятся списки серверов, IP-адреса, почты клиентов, root-пароли и пароли удалённых консолей. У части операторов — доступ к физическим узлам с клиентскими виртуальными машинами.
  • 17 октября — на части узлов FirstVDS работает программа-сборщик данных: она подключает диски клиентских VPS в режиме «только для чтения», копирует файлы и отправляет их на сервер злоумышленников.
  • 18 октября — FirstVDS публично предупреждает клиентов, отключает внешний доступ к панели и блокирует сервер атакующих. О своих инцидентах сообщают MHost, HSH Network, YaColo, ForestsNet Cloud и Senko Digital.
  • 19–20 октября — ISPsystem выпускает первые исправления; 20 октября вендор официально подтверждает инцидент, связанный с уязвимостью в одной из сборок VMmanager 6.
  • 22–25 октября — вендор сообщает о стабилизации ситуации и выпуске финального обновления безопасности; технические детали уязвимости и вектор атаки на момент публикации не раскрыты, идентификатор CVE не присвоен.

Что именно украли

По данным пострадавших провайдеров, программа-сборщик искала и копировала с дисков клиентских VPS:

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

Почему на серверах нет следов взлома

Ключевая особенность атаки: сборщик работал на узле виртуализации, а не внутри гостевых систем. Диски виртуальных машин подключались на уровне гипервизора в режиме чтения, код внутри клиентских ОС не выполнялся, файлы не изменялись. Поэтому серверы продолжали работать как обычно, а проверка auth.log или lastb внутри VPS ничего не показывает — копирование происходило «этажом ниже». Отсутствие следов взлома внутри сервера не означает, что данные не скопированы: если ваш узел был затронут, считайте все хранившиеся на диске пароли и ключи скомпрометированными.

«Молчаливые патчи» и позиция вендора

ISPsystem подтвердила инцидент лишь 20 октября — спустя трое суток после активной фазы атаки и после публичных заявлений пострадавших провайдеров. Обновления выходили с пометкой «исправление ошибок безопасности» без бюллетеня с описанием уязвимости, затронутых компонентов и обходных решений — исследователи назвали это практикой silent patching («молчаливое исправление»). FirstVDS не стал дожидаться выводов вендора и провёл собственное техническое расследование, держа инфраструктуру в изоляции до полной проверки узлов.

Что сделать владельцу VPS: чек-лист после утечки

Если ваш сервер размещался у провайдера, пострадавшего от взлома VMmanager 6, действуйте по плану — даже если сервер работает нормально:

  1. Смените все пароли — root, пользователи системы, панели управления, CMS, базы данных.
  2. Перегенерируйте SSH-ключи — создайте новые пары ключей, старые удалите из authorized_keys и отзовите во всех сервисах, где они использовались (GitHub, GitLab, CI/CD).
  3. Отзовите токены и API-ключи — облачные токены, ключи платёжных систем, репозиториев, мониторинга и любых сторонних API, которые хранились на сервере.
  4. Выведите криптовалюту — если на сервере были кошельки, сид-фразы или ключи валидаторов, переведите средства на новые кошельки с чистого устройства.
  5. Проверьте журналы после 17 октября — входы в сторонние сервисы, активность API-ключей, необычные сессии.
  6. Сделайте полный бэкап — и храните его вне инфраструктуры одного провайдера, по правилу 3-2-1.

Урок инцидента: риск общего управляющего слоя

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

Команда AZERTA поэтому изначально строит управляющий контур иначе: панель управления и бекенд виртуализации — собственная разработка, которая работает только на нашей инфраструктуре. Мы не используем VMmanager, DCImanager и другое стороннее ПО для управления VPS. Это не делает нас «неуязвимыми» — так не бывает, — но устраняет риск массовой 0-day уязвимости, общей для десятков хостеров: мы сами знаем каждый модуль своего кода, сами аудируем его и сами выпускаем исправления, не ожидая патчей стороннего вендора.

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

Источники

Материал обновляется по мере публикации вендором технических деталей инцидента.