Уязвимости в VMmanager 6 использовали для атак на хостинг-провайдеров. FirstVDS подтвердил кражу данных с части клиентских серверов. При этом сайты могли продолжать работать: злоумышленники читали диски со стороны инфраструктуры хостера. Формулировка «взломали половину Рунета» не подкреплена опубликованной статистикой. Но для владельцев затронутых серверов проблема вполне конкретная: пароли и ключи могли уйти вместе с файлами.
Представьте гостиницу: дверь вашего номера заперта, но у постороннего появился доступ к служебной системе, управляющей номерами. Примерно так различаются защита сайта внутри виртуального сервера и безопасность платформы, которой управляет провайдер. Зелёная лампочка «работает» в этой истории — слабое утешение: сервер жив, секреты могли уехать.
Материал подготовлен по открытым сообщениям провайдеров и документации, проверенным 20 октября 2026 года. Статус конкретного сервера необходимо уточнять у его владельца или хостера.
Что подтвердили провайдеры
FirstVDS. В уведомлении об инциденте компания сообщила об атаке 17 октября на часть узлов виртуализации. Программа подключала диски клиентских ВМ для чтения и отправляла собранные файлы атакующим. Внутри гостевых систем она не запускалась. Получателям персональных уведомлений провайдер рекомендует считать данные скопированными. Отсутствие письма означает, что компания пока не обнаружила следов атаки на соответствующих узлах, а не даёт бессрочную гарантию безопасности.
ForestsNet Cloud. Провайдер признал компрометацию базы панели, содержащей сведения о серверах, адреса почты и пароли root, заданные через панель. Первые следы он относит к 12 октября, запуск сборщика на сервере управления — к вечеру 16 октября. Компания проверила узлы с клиентскими ВМ и не нашла признаков вмешательства, но полностью исключить чтение клиентских данных не смогла. После установки исправления 2026.05.2-6, смены служебных доступов и дополнительной фильтрации провайдер открыл панель 18 октября. Это описание его собственного решения, а не универсальная рекомендация для других установок.
Senko Digital. В отчёте об инциденте компания датирует проникновение в свою панель 12 октября, 03:01 UTC. По её данным, быстрое ограничение внешнего доступа остановило продвижение атаки: признаков чтения или копирования клиентских ВМ не обнаружено. Провайдер перенёс управление на новую установку, сменил доступы и оставил панель закрытой для публичного доступа. Таким образом, последствия у разных компаний различались: взлом панели не во всех случаях означал подтверждённую кражу файлов клиентов.
Помимо названных выше компаний, vc.ru в пересказе материала РБК перечисляет MHost, HSH Network и YaColo как провайдеров, сообщивших об атаке. Эти упоминания не устанавливают одинаковый объём утечки у всех компаний: его нужно выяснять по результатам расследования конкретного хостера.
При чём здесь «Группа Астра» и что она ответила
VMmanager разработан ISPsystem, вошедшей в контур «Группы Астра» в 2022 году. По официальному сообщению о сделке, «Астра» получила 70% акций, а заявленный объём инвестиций составлял 2,5 млрд рублей. В том же сообщении отдельно оговорено: ISPmanager в сделку не вошёл, его развитием должна была заниматься отдельная компания. Это ещё одна причина не смешивать названия продуктов.
Представитель группы сообщил РБК, что компании известно об инциденте с уязвимостью в одной из сборок VMmanager, проводится проверка и поддерживается контакт с заказчиками. По его словам, исправления выпущены и рекомендованы к установке; конкретные затронутые инфраструктуры компания не называет из соображений безопасности. Комментарий компании и данные торгов приводит РБК.
На фоне сообщений об атаке 20 октября акции «Группы Астра» внутри дня снижались на 3,94%, до 212,3 рубля: РБК приводит данные на 11:20 МСК. Это внутридневной минимум на указанный момент, а не итог торгов и не текущая котировка.
В пересказе vc.ru также говорится примерно о 30 организациях, представленных среди клиентов VMmanager. Это не число пострадавших и не полный размер клиентской базы. Использование платформы медицинским учреждением или облачной компанией само по себе не доказывает утечку их данных.
FirstVDS — не начало истории: что известно о старых уязвимостях
Проблемы безопасности у этих продуктов находили и раньше. 1 мая 2019 года исследователи Check Point опубликовали разбор перехвата пользовательских сессий в тогдашнем общем ядре продуктов ISPsystem. Уязвимость позволяла получить права другой активной сессии, а вместе с ними — доступ к управляемым ресурсам. В перечне фигурировали ISPmanager, BILLmanager, DCImanager, VMmanager и другие продукты того поколения. Исследователи сообщили об исправлении в версии ядра 5.178.2.
13 сентября 2021 года уже сам ISPsystem подтвердил отдельную уязвимость VMmanager 6 и сообщил, что устранил её релизом 2021.09.1-1 от 10 сентября. Разработчик описал условия воспроизведения как частный случай и рекомендовал обновление и ограничение доступа к критичным сервисам.
Эти публикации подтверждают историю уязвимостей, но не существование одной незакрытой «дыры» с 2019 или 2021 года. Связать прежние взломы хостингов с нынешней кампанией можно только через совпадающие технические следы: конкретную ошибку, уязвимые сборки, журналы и инструменты атакующих. Таких сопоставлений в изученных материалах нет.
В октябрьской кампании атаки действительно начались до сообщения FirstVDS: собственные следы Senko и ForestsNet относятся к 12 октября. Поэтому точнее говорить, что FirstVDS публично подтвердил один из эпизодов более широкой кампании, а не первым установил причину всех прежних взломов.
Версия «получили доступ к дочерней панели — вышли на всех» требует уточнения. Повышение прав внутри одной управляющей платформы действительно может поставить под угрозу множество обслуживаемых ВМ. Но клиентский кабинет, сервер управления и гостевая ВМ — разные компоненты. Доступ к одному из них не означает автоматический доступ ко всем независимым провайдерам, использующим тот же продукт.
Как работала атака: три разных уровня доступа
VMmanager — платформа управления виртуальной инфраструктурой: она помогает создавать ВМ и управлять их ресурсами. Это более привилегированный уровень, чем панель отдельного сайта. Назначение продукта описано в документации разработчика.
- Вход в управляющую платформу. Senko описывает цепочку ошибок API, позволявшую добраться до внутренних контейнеров без учётной записи. Один из задействованных механизмов был связан с подключением ISO-образов и запуском задания с данными атакующего.
- Доступ к инфраструктуре. В исследованных Senko материалах кампании встречались скрытые средства повторного доступа, поддельные службы, выгрузка базы платформы и восстановление ключей API злоумышленников. Это возможности обнаруженного инструментария, а не доказательство их применения у каждого хостера.
- Чтение клиентских дисков. Такой этап подтвердил FirstVDS. Для него не обязательно взламывать WordPress, подбирать пароль SSH или запускать вирус внутри клиентской ОС: доступ получают на уровне обслуживающего её узла.
Практический вывод: проверка только журналов входа внутри VPS не исключает чтение диска извне. При этом журналы всё равно нужны — уже украденные ключи могли использовать для последующих входов. Обновление платформы и отзыв похищенных доступов решают разные задачи.
Что могло утечь
FirstVDS перечисляет пароли, SSH- и API-ключи, облачные токены, конфигурации, историю команд, криптокошельки и пользовательские файлы. Это перечень категорий, а не подтверждение наличия каждого типа данных на каждой ВМ. Секреты из конфигурации могут открыть доступ и к внешним сервисам — облаку, репозиторию, почте или платёжной интеграции. Источник: FirstVDS.
Чтение публичного SSH-ключа само по себе не раскрывает соответствующий закрытый ключ. Но закрытые ключи и действующие токены, действительно хранившиеся на затронутом сервере, требуют отдельной проверки и перевыпуска. Утечка файла с хешами паролей тоже отличается от утечки готовых паролей, хотя создаёт риск их подбора.
Есть ли риск для ISPmanager, BILLmanager и других продуктов
VMmanager и ispmanager — разные продукты. Первый управляет виртуальной инфраструктурой, второй используется для управления веб-сервером и сайтами. Сам разработчик ispmanager отдельно описывает своё ПО и продукты ISPsystem, а также интеграции между ними. В изученных первоисточниках нет подтверждения, что описанная цепочка уязвимостей существует непосредственно в ispmanager.
Таблица ниже — оценка возможных путей риска по опубликованному механизму атаки, а не список взломанных продуктов.
| Что вы используете | Что означает этот инцидент | Что проверить |
|---|---|---|
| VMmanager 6 | Продукт прямо фигурирует в сообщениях об эксплуатации уязвимостей. | Сборку, внешний доступ к панели и API, следы проникновения, состояние узлов и служебных ключей. |
| ispmanager внутри VPS | Косвенный риск, если ВМ размещена на затронутом узле: файлы могут читать независимо от защищённости панели сайта. | Использует ли хостер VMmanager и затронута ли конкретная ВМ; доступы сайта, БД и почты. |
| ispmanager на отдельном физическом сервере | Одно наличие этой панели не связывает сервер с атакой. | Способ управления сервером и общие ключи с другой инфраструктурой. Доказательств отдельной уязвимости ispmanager в этой кампании нет. |
| BILLmanager | Взлом продукта этой цепочкой не подтверждён. Возможен риск через размещение или украденные секреты интеграции. | Где работает биллинг и какие доступы к нему находились в скомпрометированной системе. |
| DCImanager, DNSmanager, IPmanager | Автоматически переносить вывод об уязвимости VMmanager на эти продукты нельзя. | Собственные уведомления безопасности, общие учётные записи и токены управления. |
| WordPress, Битрикс, VPN или приложение без панели | Отсутствие VMmanager внутри вашей ОС не защищает от компрометации платформы хостера. | Конкретный сервер, его диски и секреты приложения. |
| VMmanager 5 или отдельная редакция ФСТЭК | По найденным сообщениям нельзя установить их затронутость этой цепочкой. | Ответ вендора именно для вашей редакции и сборки. Не переносить номера исправлений между ветками. |
Это не только теоретическая связь продуктов: ForestsNet сообщил, что заменил, среди прочего, служебные пароли интеграций биллинга и поддержки. При этом его клиентский кабинет с платежами расположен отдельно и, по утверждению компании, недоступен из панели виртуализации. Отчёт провайдера.
Почему последствия дошли до Битрикс24
Команда Битрикс24 сообщила о превентивном перевыпуске OAuth-секретов потенциально затронутых сторонних приложений 18 октября. Указанный охват — 10 разработчиков. Причина — возможное хранение доступов на внешних серверах. Это не означает взлом облачного Битрикс24 или каждого приложения. Локальные приложения и входящие вебхуки автоматически этой мерой не охвачены: администраторам необходимо проверить их отдельно.
Какие исправления вышли и можно ли уже открывать панель
При прямой проверке журнала ISPsystem 20 октября последними были указаны:
| Ветка | Версия | Дата | Описание разработчика |
|---|---|---|---|
| Stable | 2026.05.2-9 | 20.10.2026 | Исправление ошибок безопасности |
| Regular | 2026.09.1-5 | 20.10.2026 | Исправление ошибок безопасности |
Записи changelog не раскрывают полного диапазона уязвимых сборок и подробностей исправленной цепочки. В изученных уведомлениях не указан подтверждённый CVE для этой кампании. Нельзя по одному номеру обновления объявлять все предыдущие версии уязвимыми, а всю инфраструктуру после установки — очищенной.
В обновлении FirstVDS от 20 октября, 09:35 МСК говорится, что работа вендора продолжается. Провайдер сохраняет закрытый доступ к панели, переносит основные функции в клиентский кабинет и пересматривает внутренние политики безопасности. Это сообщение и новые записи changelog — разные по времени и смыслу сведения. Сам выход патча не равен разрешению открыть панель в интернет и не отменяет расследование возможного проникновения.
Что делать владельцу сервера
Ниже — практические выводы из уведомлений провайдеров. Не передавайте пароли и ключи людям, предлагающим «проверку взлома» в личных сообщениях: используйте официальный кабинет хостера.
- Уточнить затронутость. Запросить у хостера проверку конкретной ВМ и узла, временного интервала и уровня доступа атакующих: панель, база управления или клиентские диски. Общего ответа «у нас всё работает» недостаточно.
- При подтверждённой компрометации — отозвать доступы. С чистого устройства менять пароли и перевыпускать секреты в доверенной среде. Старые токены нужно отключить: создание нового не лишает атакующего старого.
- Проверить внешние системы. Просмотреть действия в облаках, репозиториях и сервисах, куда давали доступ лежавшие на сервере ключи. Период проверки уточнить у провайдера: первые опубликованные следы кампании предшествуют 17 октября.
- Если на сервере были секреты кошельков, следовать рекомендации провайдера о переносе средств в новый кошелёк, созданный на чистом устройстве. Смена пароля старого кошелька не отзывает уже скопированную seed-фразу.
- Сохранить материалы для расследования. Согласовать с хостером сбор журналов и восстановление в доверенной среде. Не уничтожать единственную копию следов поспешной переустановкой. Новые секреты не следует оставлять в системе, которую всё ещё контролирует посторонний.
Операторам VMmanager нужна проверка самой платформы и узлов, ограничение доступа к управляющим интерфейсам, актуальные рекомендации поддержки для своей сборки и замена служебных доступов. Один патч не удаляет автоматически ранее установленное средство повторного доступа. Источник для сопоставления мер — отчёт Senko Digital.
Что остаётся неизвестным
Не опубликован единый проверенный список пострадавших организаций, число скопированных ВМ и объём похищенного. Наличие банка, университета или больницы среди пользователей продукта само по себе не подтверждает их взлом. Равным образом «десятки тысяч машин у провайдера» не означают десятки тысяч скомпрометированных машин.
Поэтому главный вопрос для клиента звучит конкретно: кто мог прочитать диск моего сервера и какие действующие доступы там лежали? Проверять нужно инфраструктуру размещения, а не только логотип панели. Исправный сайт и отсутствие подозрительных SSH-входов не дают ответа на этот вопрос.