Взлом VMmanager и FirstVDS: что случилось и что делать владельцам серверов

Коротко. С 11 по 17 октября 2026 года злоумышленники воспользовались уязвимостью в VMmanager 6 — системе, через которую многие российские хостинги управляют виртуальными серверами. У FirstVDS они подключали диски клиентских серверов только на чтение и копировали с них пароли, ключи, токены, конфиги и криптокошельки. Сами серверы при этом работали как обычно, поэтому внутри них следов почти нет. Пострадали и другие провайдеры: ForestsNet Cloud, MHost, YaColo, HSH Network. Если ваш сервер стоит у хостинга на VMmanager, исходите из того, что всё, что лежало на диске, могло утечь, и меняйте доступы. Обновление панели у хостинга уже украденные пароли не отменяет.

Статья собрана по публичным заявлениям провайдеров и разработчика на 22 октября 2026 года. Расследование не закончено, FirstVDS обещает подробный отчёт позже — будем обновлять материал.

Что случилось с VMmanager и FirstVDS

VMmanager 6 разрабатывает компания ISPsystem, которая входит в «Группу Астра». Через эту панель хостинг создаёт виртуальные серверы, переустанавливает систему, задаёт root-пароль и открывает консоль. Панелью пользуются и хостинги, и компании, у которых собственная виртуализация.

По данным компании Senko Digital, которая опубликовала технический разбор, атакующий использовал цепочку ошибок в программном интерфейсе VMmanager и добрался до функции подключения ISO-образов. Это позволило выполнять команды на сервере панели без учётной записи. Номер уязвимости (CVE) и номер затронутой сборки разработчик не раскрывает: по его словам, это опасно, пока не все клиенты обновились.

Дальше у разных провайдеров атака зашла на разную глубину:

• FirstVDS — на части узлов виртуализации работала программа, которая подключала диски клиентских серверов в режиме «только чтение», собирала с них данные и отправляла на сервер злоумышленников. Клиентам, чьи серверы попали под атаку, провайдер разослал уведомления. В уведомлении указан период 17 октября с 12:27 до 22:34 по Москве.
• ForestsNet Cloud — утекла база панели: список серверов с IP-адресами, почта владельцев, root-пароли, заданные через панель при заказе, переустановке или смене пароля, и пароли консоли VNC. Следов программы-сборщика на клиентских узлах провайдер не нашёл, но полностью доступ к ним не исключает.
• MHost — нашёл на узлах программу, искавшую конфиденциальные файлы, отключал оборудование и поднимал серверы поэтапно, заменив служебные ключи.
• YaColo — атаковали несколько панелей в Кемерове, Москве и Санкт-Петербурге, прямых признаков кражи данных провайдер не нашёл.
• Senko Digital — атакующий проник 12 октября и создал два администраторских API-токена сроком до 2036 года. Их нашли 14 октября и отозвали. Проверка не нашла чтения клиентских дисков.

По оценке Senko Digital, кампания затронула как минимум несколько десятков провайдеров. Подтверждённого полного списка нет, «Группа Астра» число пострадавших не называет.

Хронология

Что могли украсть

FirstVDS в уведомлении клиентам перечисляет, что искала программа злоумышленников:

• SSH-ключи и authorized_keys, файлы паролей, хранилища KeePass и GPG;
• доступы к облакам и DevOps: AWS, Google Cloud, Azure, Kubernetes, Docker, Terraform, токены GitHub, GitLab, npm;
• конфиги приложений и баз данных: .env, docker-compose, строки подключения к PostgreSQL, MySQL, MongoDB, Redis;
• криптокошельки, seed-фразы, API-ключи бирж;
• API-ключи OpenAI и Anthropic;
• сохранённые пароли и cookies браузеров, история команд;
• пароли резервных копий.

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

Важная деталь: программа не запускалась внутри серверов и ничего не меняла на дисках. Поэтому в логах самого сервера кражу не видно, и проверка «вроде всё чисто» ничего не доказывает. FirstVDS отдельно предупреждает: отсутствие уведомления тоже не гарантия безопасности.

Какие пароли и ключи менять владельцу сервера

Порядок важен: сначала то, чем можно воспользоваться быстрее всего.

1. Криптовалюта. Если на сервере были кошельки, seed-фразы или ключи бирж — переведите средства на новый кошелёк, созданный на чистом устройстве, и отзовите ключи бирж.
2. Root-пароль и SSH. Смените пароль root, особенно если он задавался через панель хостинга, — у части провайдеров утекли именно такие пароли. Выпустите новые SSH-ключи и удалите старые из authorized_keys: новый ключ без отзыва старого ничего не защищает.
3. Токены и API-ключи. Облака, CI/CD, репозитории, ИИ-сервисы, платёжные системы (ЮKassa, Robokassa, CloudPayments и другие), токены Telegram-ботов, API-ключи карт и сервисов рассылок. Старый ключ нужно именно отозвать.
4. Базы данных и сервисы из конфигов. Пароли пользователей MySQL/PostgreSQL из wp-config.php, bitrix/.settings.php, .env, пароли SMTP. Не забудьте пароли, которые могли остаться в истории команд.
5. Панели и почта. Пароли ISPmanager, HestiaCP, FTP, почтовых ящиков и администраторов CMS.
6. Резервные копии. Смените пароли и ключи шифрования бэкапов, проверьте, что сами копии на месте и не изменены.
7. Логи внешних сервисов. Посмотрите входы и действия в облаках, репозиториях, платёжных кабинетах и на биржах начиная с 11 октября.

Как проверить, не воспользовались ли украденным

Кражу на самом сервере не видно, но использование украденных паролей обычно оставляет следы. Минимальный набор проверок под root (Debian/Ubuntu):

# входы по SSH с 11 октября: метод, пользователь, IP
journalctl -u ssh -u sshd --since 2026-10-11 | grep Accepted

# чужие ключи
cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys

# новые пользователи и автозапуск
awk -F: '$3==0 || $3>=1000' /etc/passwd
crontab -l; ls -la /etc/cron.d /var/spool/cron/crontabs
find /etc/systemd /etc/cron* /etc/ssh /root/.ssh -newerct 2026-10-11 -type f

# изменённые системные файлы и PHP-файлы сайтов
dpkg --verify | grep -v ' c /'
find /var/www -newerct 2026-10-17 -name '*.php'

Любой вход с незнакомого IP, незнакомый ключ, новый пользователь или задача в cron — повод разбираться всерьёз. В этом случае хостинги советуют переустановить систему и восстановить данные из проверенной резервной копии, а не чистить сервер вручную.

Заодно проверьте на сервере версию PHP: 21 октября вышли исправления уязвимости PHP2Shell, через которую сайт можно взломать одним запросом, и атаки на неё уже идут.

Если у вас своя VMmanager

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

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

Персональные данные

Если на сервере хранились персональные данные ваших клиентов — заявки, заказы, база покупателей, — утечка касается и их. Закон о персональных данных обязывает оператора уведомить Роскомнадзор об инциденте в течение 24 часов с момента, как о нём стало известно, а в течение 72 часов — о результатах расследования. FirstVDS советует обсудить это с юристом, и мы присоединяемся: обязанность зависит от того, какие именно данные были на сервере.

Что закон о персональных данных требует от сайта, мы разбирали в статье «Требования Роскомнадзора по 152-ФЗ в 2026 году».

Частые вопросы

Как понять, затронул ли взлом мой сервер на FirstVDS?
FirstVDS разослал уведомления клиентам, чьи серверы попали под атаку; в уведомлении указан период 17 октября с 12:27 до 22:34 по Москве. Но провайдер сам предупреждает: отсутствие уведомления не гарантирует безопасность, а в логах самого сервера кражу не видно.

Уведомления не было. Нужно ли менять пароли?
Да, если сервер стоит у хостинга на VMmanager 6. Подтверждённого списка пострадавших нет, программа злоумышленников читала диски снаружи и не оставляла следов внутри сервера. Безопаснее считать известным всё, что лежало на диске.

Какие хостинги пострадали от атаки на VMmanager?
О последствиях публично сообщили FirstVDS, ForestsNet Cloud, MHost, YaColo и Senko Digital, также упоминается HSH Network. По оценке Senko Digital, кампания затронула как минимум несколько десятков провайдеров; полного списка нет.

Что менять в первую очередь?
Криптокошельки и ключи бирж, затем root-пароль и SSH-ключи (старые удалить из authorized_keys), токены и API-ключи облаков, платёжных систем и ботов, пароли баз данных из конфигов, пароли панелей, почты и резервных копий.

Хостинг обновил VMmanager. Этого достаточно?
Нет. Обновление закрывает уязвимость, но уже скопированные пароли, ключи и токены остаются у злоумышленников. Их нужно сменить и отозвать, а затем проверить входы во внешние сервисы начиная с 11 октября.

Нужно ли уведомлять Роскомнадзор?
Если на сервере были персональные данные клиентов, закон обязывает оператора уведомить Роскомнадзор об инциденте в течение 24 часов, а о результатах расследования — в течение 72 часов. Обязанность зависит от того, какие данные хранились, поэтому обсудите её с юристом.

Что сделали мы

Часть сайтов и сервисов наших клиентов работает на FirstVDS. 21–22 октября мы проверили все серверы клиентов на поддержке, к которым у нас есть доступ: входы по SSH и в панели, ключи, пользователей, автозапуск, системные файлы и изменённые файлы сайтов. Следов использования украденных данных не нашли. Пароли и ключи на этих серверах всё равно меняем: как написано выше, чистые логи не доказывают, что данные не скопировали.

Если ваш сервер стоит на FirstVDS или у другого хостинга на VMmanager и вы не уверены, что всё сделали, — напишите. Проверим сервер и подскажем, какие доступы менять в первую очередь.

Источники

• Хабр: FirstVDS — злоумышленники получили доступ к части инфраструктуры через VMmanager
• SecurityLab: разбор по провайдерам и анализ Senko Digital
• Хакер: хостеры пострадали от атак на уязвимость в VMmanager
• SecPost: ISPsystem признала взлом VMmanager 6 и выдала инструкции
• SecPost: FirstVDS останется на VMmanager
• CNews: российская система управления серверами взломана
• The Record: Hackers steal customer data from FirstVDS