Взлом FirstVDS через уязвимость в VMmanager 6: что известно и что делать клиентам

В октябре 2026 года через уязвимость в VMmanager 6 — платформе виртуализации компании ISPsystem из «Группы Астра» — атаковали сразу несколько хостинг-провайдеров. Самый заметный случай — взлом FirstVDS. 18 октября компания публично сообщила: на части её узлов виртуализации работала программа, которая подключала диски клиентских VPS и копировала с них ключи, пароли, конфиги и криптокошельки. Об атаках на свои панели VMmanager написали ForestsNet Cloud и Senko Digital. ITLDC сообщила об инциденте в системе управления VDS, не называя продукт, а Gcore закрыла панели VMmanager 6 и DCImanager 6 из-за уязвимости в ПО вендора.

Мы собрали в одном материале всё, что на 20 октября 2026 года известно из официальных заявлений вендора и хостеров. Факты приводим со ссылками на источники и отдельно отмечаем сведения, которые известны только по пересказам СМИ. Слухи и частные мнения вынесли в отдельный блок с пометкой. Ниже — пошаговые действия для клиентов VPS и для владельцев VMmanager. Материал обновляем по мере появления новых данных.

Коротко: что известно на 20 октября

• Что взломали. VMmanager 6 — панель, через которую хостеры управляют гипервизорами и виртуальными серверами клиентов. Вендор подтвердил инцидент «в одной из сборок VMmanager 6».
• Когда. Единой даты нет. Senko Digital зафиксировала вход 12 октября. ForestsNet пишет о заражении панелей с 11 по 16 октября и об активной фазе атаки на хостеров в ночь на 17 октября.
• Кто сообщил. Об атаке через VMmanager — FirstVDS, ForestsNet Cloud и Senko Digital. Об инциденте без названия продукта — ITLDC. О закрытии панелей из-за уязвимости вендора — Gcore. По данным СМИ — также MHost, YaColo и HSH Network.
• Что могло утечь. С дисков VPS — SSH- и API-ключи, токены, пароли, конфиги, история команд, криптокошельки. Из базы панели — IP-адреса, email и root-пароли, заданные через панель.
• Что неизвестно. CVE, номер уязвимой сборки, индикаторы компрометации, число пострадавших и атрибуция. Способ проникновения вендор не раскрыл — техническое описание своей атаки опубликовала только Senko Digital.

Что такое VMmanager и почему один взлом задел многих

VMmanager — российская платформа управления виртуализацией на базе KVM от ISPsystem. Хостинг-провайдер ставит её поверх своих физических серверов и через одну панель создаёт, переустанавливает и обслуживает виртуальные машины клиентов. Подробнее о том, как устроены такие системы, мы писали в материалах о виртуализации серверов и о панелях управления хостингом.

Панель виртуализации стоит на уровень выше клиентских серверов: у неё есть доступ к узлам, где лежат диски всех VPS. Если атакующий получает управление панелью, ему не нужно взламывать каждую виртуальную машину отдельно. По данным «Группы Астра», в 2025 году VMmanager был установлен более чем на 6000 серверов (SecPost, 19.10.2026). Это число инсталляций, а не число пострадавших.

«Группа Астра» купила 70% ISPsystem в марте 2022 года, 30% осталось у основателя Павла Гуральника (CNews, 20.10.2026). Среди продуктов компании — также DCImanager для управления выделенными серверами. О компрометации панели ISPmanager, которую часто путают с VMmanager, в этом инциденте не сообщалось.

Хронология атаки

Senko Digital и SecurityLab отдельно предупреждают: 17 октября — дата атаки на FirstVDS, а не начало кампании. У разных провайдеров даты проникновения разные.

Кто пострадал: взлом FirstVDS и других хостеров

Официального списка пострадавших нет. ISPsystem не раскрывает перечень и число затронутых операторов: по словам компании, это создаст дополнительные риски, пока не обновятся все заказчики (ISPsystem, 20.10.2026).

Сообщили на своих ресурсах

Известно по публикациям СМИ

• MHost — нашла на узлах вредонос, который искал конфиденциальные файлы, отключила оборудование и 19.10 запустила серверы после проверки и замены служебных ключей (SecurityLab, 20.10.2026). Собственного заявления компании мы не нашли.
• YaColo — затронуты «несколько панелей» в Кемерове, Москве и Санкт-Петербурге, прямых доказательств кражи данных нет (Forbes, 20.10.2026).
• HSH Network — упомянута среди сообщивших об атаке, подробностей нет (vc.ru, 20.10.2026).
• Datagio — временно отключала узлы в качестве меры предосторожности, кражу файлов не подтверждала. SecurityLab отключение узлов подтверждением утечки не считает.

Senko Digital оценивает масштаб кампании в «как минимум несколько десятков» провайдеров. В пересказах встречается цифра 37 — это число участников общего чата хостеров, где разбирали инцидент, а не число взломанных компаний (ForestsNet).

Как была устроена атака

По открытым данным, у атаки было два канала утечки.

База панели. Получив доступ к VMmanager, атакующие выгружали его базу данных. Там хранятся список виртуальных серверов и их IP, email учётных записей, пароли VNC-консоли и root-пароли, заданные через панель при заказе или переустановке (ForestsNet). Этот канал опасен даже там, где до дисков дело не дошло.

Диски клиентских VPS. У части провайдеров атакующие прошли с панели на узлы виртуализации и запустили там программу-сборщик. Она подключала диски виртуальных машин в режиме «только чтение» и отправляла найденные файлы на внешний сервер (FirstVDS). Внутри VPS программа не запускалась и ничего не меняла. Антивирус и журналы гостевой системы следов не покажут: сервер продолжал работать как обычно.

Вектор проникновения вендор не раскрывает. Единственное техническое описание опубликовала Senko Digital. Это цепочка уязвимостей в API: один из эндпоинтов функции подключения ISO позволял запустить произвольную задачу без учётной записи и авторизации. Дальше атакующий создал админские API-токены, маскировал активность под штатные задачи платформы и пытался подчистить журналы (Senko). ISPsystem это описание не подтверждала.

Побег из виртуальной машины или взлом изоляции KVM никто из участников не заявлял (SecurityLab, 18.10.2026). Атака шла через систему управления, а не через гипервизор как таковой.

Что искал сборщик

По заявлению FirstVDS и публикациям SecurityLab, сборщик искал такие данные (какие именно файлы ушли у конкретных клиентов, не установлено):

• SSH-ключи, API-ключи и токены облачных сервисов (AWS, Google Cloud, Azure, OpenStack);
• пароли и строки подключения к базам данных (PostgreSQL, MySQL, MongoDB, Redis), файлы .env, конфиги Docker, Kubernetes и Terraform;
• токены GitHub, GitLab и npm, ключи API нейросетевых сервисов;
• пароли бэкапов Restic и Borg;
• криптокошельки, приватные ключи, seed-фразы и ключи валидаторов;
• сохранённые пароли и cookies браузеров, базы KeePass и ключи GPG;
• историю команд и пользовательские файлы.

На 20 октября никто публично не подтвердил вторичных атак с использованием украденного. Никита Цаплин (RUVDS) предупреждает, что это утечка, а не поломка: украденные ключи могут «всплыть» позже, даже после исправления уязвимости (Forbes, 20.10.2026).

Официальная позиция: ISPsystem и «Группа Астра»

20 октября ISPsystem опубликовала заявление «Об инциденте, связанном с уязвимостью в одной из сборок VMmanager 6». Компания называет ситуацию сложной, но контролируемой, и сообщает, что закрывает уязвимость, устраняет последствия и проводит проверку (ISPsystem). В пресс-релизе «Группы Астра» сказано, что «ситуация полностью контролируется на стороне вендора», а поддержка переведена в усиленный режим (astra.ru).

Для всех инсталляций на период инцидента вендор назвал три обязательные меры:

1. закрыть на межсетевом экране доступ к платформе и узлам виртуализации — и входящие, и исходящие соединения — для всех, кроме доверенных администраторов и техподдержки ISPsystem;
2. разрешить SSH к узлам и платформе только с доверенных адресов;
3. оперативно сменить все пароли.

CVE, номер уязвимой сборки, версию исправления и индикаторы компрометации вендор не приводит. В журнале изменений VMmanager 6 с 14 по 20 октября вышло семь сборок. У каждой указано «Исправление ошибок безопасности», без технических подробностей.

Источник: changelog VMmanager 6. При этом FirstVDS 19 и 20 октября сообщала, что уязвимость закрыта не полностью и открывать панель вендор пока не рекомендует.

Компенсаций на 20 октября не объявили ни вендор, ни хостеры. Публичной реакции ФСТЭК, НКЦКИ и Роскомнадзора мы не нашли. Акции «Группы Астра» 20 октября на фоне новостей о взломе снижались до 3,94% (fomag.ru).

Что говорят: слухи и неподтверждённое

Что делать клиенту VPS прямо сейчас

Шаги ниже собраны из рекомендаций FirstVDS, ForestsNet, ITLDC и Senko Digital. ForestsNet советует пройти их и клиентам других хостеров на VMmanager 6, а не только тем, кто получил письмо. FirstVDS прямо пишет: если уведомления нет, это значит лишь, что следов атаки на ваших узлах не нашли.

1. Начните с криптовалюты. Если на сервере были кошельки, приватные ключи или seed-фразы, переведите средства на новые кошельки, созданные на чистом устройстве. Смена пароля кошелька не помогает.
2. Отзовите ключи и токены в источнике: в облачных консолях, на GitHub и GitLab, в платёжных системах, в API нейросетей. Выпустить новый ключ мало — старый нужно удалить. Проверьте копии старых ключей в скриптах, CI/CD и агентах.
3. Смените все пароли, которые лежали на сервере: root и пользователей, баз данных, панелей сайтов, почты, бэкапов.
4. Перейдите на вход по SSH-ключам и отключите вход по паролю, особенно если root-пароль задавался через панель хостера. Пошагово это описано в нашем гайде по настройке SSH.
5. Проверьте сервер на следы закрепления: входы, ключи, пользователи, задачи, службы. Хостеры советуют смотреть с 17 октября; с учётом хронологии ForestsNet мы рекомендуем начинать с 11 октября.
6. Решите, нужна ли переустановка. MHost советует переразвернуть систему и восстановиться из проверенного бэкапа. ForestsNet предупреждает: одна переустановка не спасает, секреты всё равно нужно сменить.
7. Проверьте бэкапы: актуальны ли, зашифрованы ли, хранятся ли отдельно от сервера, проходит ли восстановление. Как это настроить — в материале о бэкапах VPS по схеме 3-2-1.
8. Оцените риски по персональным данным клиентов. Если они хранились на сервере, FirstVDS советует проконсультироваться с юристом насчёт уведомления Роскомнадзора по 152-ФЗ.

Базовая проверка сервера на Ubuntu и Debian:

# кто и когда входил
last -F | head -50
journalctl -u ssh --since "2026-10-11" | grep -E "Accepted|Failed"

# чужие ключи в authorized_keys
cat /root/.ssh/authorized_keys
for d in /home/*; do echo "== $d"; cat "$d/.ssh/authorized_keys" 2>/dev/null; done

# новые пользователи и права sudo
awk -F: '$3 >= 1000 {print $1, $6, $7}' /etc/passwd
getent group sudo

# задачи по расписанию и службы, изменённые после 11 октября
crontab -l; ls -la /etc/cron.* /var/spool/cron/crontabs 2>/dev/null
find /etc/systemd/system /lib/systemd/system -newermt "2026-10-11" -type f

# новый SSH-ключ создавайте на своём компьютере, не на сервере
ssh-keygen -t ed25519

После проверки закройте лишние порты и ограничьте SSH доверенными адресами — пригодится наш разбор файрволов ufw и nftables. Для отслеживания входов и аномалий подойдёт мониторинг сервера.

Что делать владельцу VMmanager

Для провайдеров и компаний с собственной инсталляцией VMmanager рекомендации вендора и практика пострадавших выглядят так:

1. Закрыть платформу и узлы на файрволе для входящих и исходящих соединений, кроме доверенных администраторов и поддержки ISPsystem.
2. Оставить SSH к узлам и платформе только с доверенных адресов.
3. Поставить актуальную сборку: на 20 октября это 2026.05.2-9 или 2026.09.1-5.
4. Проверить API-токены администраторов на неизвестные и долгоживущие, проверить задачи платформы (так атаку нашли в Senko Digital).
5. Заменить SSH-ключ управления на всех узлах по инструкции вендора, перенести панель на чистый сервер без доступа из интернета.
6. Сменить все пароли и заменить служебные ключи, которые хранились на сервере панели. Если панель всё же нужна снаружи — только за фильтрующим прокси или VPN с многофакторной аутентификацией.
7. Запретить SSH из виртуальных машин к узлам.

Контекст: прошлые инциденты и мировые аналоги

Это не первая серьёзная уязвимость в продуктах ISPsystem. В сентябре 2021 года компания закрыла уязвимость в VMmanager 6 (релиз 2021.09.1-1) и рекомендовала ограничить SSH-доступ к критичным сервисам по списку адресов (ISPsystem, 13.09.2021). В 2019 году Check Point Research нашла предсказуемые идентификаторы сессий во всех продуктах на COREmanager, включая ISPmanager и VMmanager; ошибку исправили в COREmanager 5.178.2 (Check Point).

В мире атаки на системы управления инфраструктурой случались и раньше. В 2021 году группировка REvil через обход аутентификации в Kaseya VSA разослала вымогатель через сервис-провайдеров: пострадали около 60 провайдеров и, по оценке Kaseya, 800–1500 компаний ниже по цепочке. В 2023 году в ходе кампании ESXiArgs были скомпрометированы более 3800 серверов VMware ESXi, доступных из интернета (CISA). Все эти случаи говорят об одном: панель, которая управляет сотнями серверов, — самая ценная цель, а держать её доступной из интернета опасно.

Как выбирать хостинг после такого инцидента

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

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

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

Что в сухом остатке

Уязвимость в VMmanager 6 дала атакующим доступ к системам управления как минимум нескольких хостеров. У части из них данные копировали прямо с дисков клиентских VPS — незаметно для владельцев серверов. Вендор подтвердил инцидент, выпустил серию исправлений, но технических деталей не раскрывает. Официального списка пострадавших и компенсаций нет.

Для клиентов вывод практический. Если вы получили уведомление, FirstVDS рекомендует считать данные с сервера скопированными. Если сервер работал на VMmanager 6, а письма нет, отзовите ключи, смените пароли и проверьте сервер на следы закрепления превентивно — не дожидаясь новостей от провайдера.

Источники

• FirstVDS — «Уязвимость VMmanager: срочно смените доступы», 18–20.10.2026; Telegram @TakeFirstNews
• ISPsystem — заявление об инциденте, 20.10.2026; changelog VMmanager 6
• «Группа Астра» — пресс-релиз, 20.10.2026
• ForestsNet Cloud — «Взлом хостингов на VMmanager 6», 18–20.10.2026
• Senko Digital — постмортем, 19.10.2026
• ITLDC — Security Notice, 18.10.2026
• Gcore — статус-страница, 18–19.10.2026
• SecurityLab — 18.10.2026, 20.10.2026
• Forbes — «Хостинг-провайдеры предупредили о взломе», 20.10.2026
• CNews — 20.10.2026; SecPost — 19.10.2026; The Record — 19.10.2026