Взлом VMmanager 6: с VPS украли ключи и пароли — что сделать владельцу сервера

17 октября через уязвимость в VMmanager 6 с клиентских VPS FirstVDS скопировали пароли, SSH- и API-ключи, токены и криптокошельки. ISPsystem подтвердила инцидент. Что сделать владельцу сервера.

17 октября 2026 года злоумышленники воспользовались уязвимостью в VMmanager 6 — российской платформе управления виртуальными серверами компании ISPsystem — и украли данные с клиентских VPS. Первым о взломе рассказал хостинг FirstVDS, 20 октября инцидент подтвердил сам разработчик. С серверов уносили пароли, SSH- и API-ключи, токены, конфиги и криптокошельки. Разбираем, что известно, кого это касается и что сделать владельцу VPS прямо сейчас.

Взлом VMmanager 6: что украли с VPS и что сделать владельцу сервера
Что копировали с дисков клиентских серверов — по сообщению FirstVDS

Что произошло

VMmanager — платформа, через которую хостинг-провайдеры и компании создают виртуальные серверы и управляют ими. Её разрабатывает ISPsystem, входящая в «Группу Астра». По данным SecPost, которые приводит CNews, VMmanager работает в паре более чем с 6 000 серверов, в том числе в государственных организациях.

18 октября хостинг FirstVDS сообщил в своём Telegram-канале, что накануне злоумышленники получили доступ к части его инфраструктуры через уязвимость в VMmanager 6. По словам провайдера, на узлах виртуализации запустили программу для кражи данных. Она подключала диски клиентских виртуальных серверов в режиме только для чтения и копировала с них:

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

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

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

Что сделали провайдер и разработчик

  • FirstVDS отключил внешний доступ к системе управления виртуализацией, заблокировал адрес сервера злоумышленников и разослал затронутым клиентам уведомления в личный кабинет и на почту со списком серверов. Кто уведомления не получил — на их узлах, по словам провайдера, следов атаки не нашли. Расследование продолжается, постмортем обещан после закрытия инцидента.
  • ISPsystem, по словам FirstVDS, выпустила промежуточный патч и работает над окончательным исправлением. Всем, кто использует VMmanager, разработчик велел на время инцидента закрыть на межсетевом экране доступ к платформе и узлам виртуализации для всех, кроме доверенных администраторов и поддержки ISPsystem, — и на входящие, и на исходящие соединения, — разрешить SSH только с доверенных адресов и сменить все пароли.

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

Как понять, касается ли это вас

По самому серверу — никак: атака шла снаружи, с узла виртуализации. Ориентиры такие:

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

Что сделать владельцу VPS, если сервер затронут

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

  1. Криптокошельки — в первую очередь перевести средства на новые кошельки, созданные на другом, чистом устройстве.
  2. Сменить все пароли и ключи, которые лежали на сервере: root и пользователей, базы данных, панели сайтов, почту, облачные сервисы, CI/CD, платёжные системы.
  3. Отозвать старые ключи, а не просто выпустить новые: в облачных консолях, в GitHub и GitLab, у платёжных провайдеров, у сервисов нейросетей.
  4. Проверить журналы входов на сервере и во всех сервисах, ключи от которых там хранились: не было ли входов с незнакомых адресов после 17 октября.
  5. Если на сервере были персональные данные клиентов — разобраться с обязанностью уведомить Роскомнадзор. По закону о персональных данных об утечке сообщают в течение 24 часов с момента, когда о ней узнали, а о результатах расследования — в течение 72 часов.

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

last -a | head -30                         # последние входы и адреса
sudo journalctl -u ssh --since "2026-10-17" | grep -i accepted
cat ~/.ssh/authorized_keys /root/.ssh/authorized_keys   # нет ли чужих ключей
awk -F: '$3 >= 1000 {print $1}' /etc/passwd  # обычные пользователи — нет ли новых
sudo crontab -l; ls /etc/cron.d/            # задания по расписанию
systemctl list-units --type=service --state=running   # незнакомые службы
ss -tnp                                     # подозрительные соединения

Что искать и как вычищать найденное, мы разбирали на реальном случае заражения одного из наших серверов — в статье «Вирус-майнер: как обнаружить и удалить». Основные команды — в шпаргалке по Linux.

Вывод: что этот взлом показывает

Атака через систему виртуализации обходит всё, что владелец VPS настраивает сам: ключ вместо пароля, fail2ban и закрытые порты защищают от входа на сервер, но не от того, кто читает его диск снаружи. Отсюда три практических правила.

  • Не держите на VPS лишних секретов. Ключи от облаков, GitHub, платёжек и нейросетей в файлах .env и истории команд — самое ценное, что уносят при таких атаках. Давайте каждому серверу ключи с минимальными правами.
  • Криптокошельки на VPS — плохая идея при любом провайдере.
  • Храните резервные копии и ключи к ним отдельно. По данным SecurityLab, которые приводит CNews, среди украденного могли оказаться пароли систем резервного копирования Restic и Borg — бэкап с паролем на том же сервере перестаёт быть защитой. Как устроить копии правильно — в статье «Резервная копия сайта».

Базовую защиту VPS всё равно стоит держать в порядке — она закрывает большинство других атак. Пошагово — в статье «Настройка VPS: SSH-ключ, ufw и fail2ban».

Источники: сообщение FirstVDS об инциденте, заявление ISPsystem, CNews (там же — данные SecurityLab и SecPost), закон № 152-ФЗ «О персональных данных». Проверено 21 октября 2026 года.

1 / 1
Оцените статью
Да будет Интернет!