17 октября злоумышленники через уязвимость в системе управления виртуализацией VMmanager 6 получили доступ к части инфраструктуры FirstVDS, сообщил провайдер в своём официальном Telegram-канале. На части узлов виртуализации запустили программу, которая подключала диски клиентских VPS в режиме только для чтения и копировала с них данные. Владельцам затронутых серверов FirstVDS разослал уведомления в личный кабинет и на почту со списком серверов и инструкцией.
VMmanager это панель виртуализации от компании ISPsystem. Через неё хостинг сам создаёт и обслуживает VPS на своём железе: заводит виртуальные машины, выделяет им диски, память и процессоры. Клиенты в неё обычно не заходят, своим сервером они управляют через личный кабинет провайдера. Поэтому дыра в такой панели бьёт сразу по всем виртуалкам на узле, как бы хорошо ни был настроен каждый отдельный сервер.
Если у вас VPS в FirstVDS, первым делом откройте личный кабинет и почту. Письма нет: по словам провайдера, это значит, что на узлах с вашим сервером следов атаки не нашли, то есть в списке затронутых его сейчас нет. Но расследование продолжается, и FirstVDS обещает сразу написать, если найдёт что-то ещё. Письмо есть: провайдер просит считать, что данные с сервера уже скопированы.
Что копировали с дисков клиентских VPS
По данным FirstVDS, программа забирала с дисков:
- пароли, ключи доступа (SSH, API, облачные сервисы) и токены;
- конфигурационные файлы и историю команд;
- криптокошельки;
- пользовательские файлы.
Собранное уходило на сервер злоумышленников. Атака задела не всю инфраструктуру, а часть узлов виртуализации и клиентские серверы, которые на них работали. Внутри самих VPS программа не запускалась и ничего не меняла на дисках, поэтому серверы работают как обычно, а следов атаки на них нет. Проверка изнутри виртуалки тут ничего не покажет: чтение шло снаружи, с узла виртуализации.
Сколько серверов и клиентов пострадало, FirstVDS не называет. Постмортем провайдер обещает опубликовать после закрытия инцидента и окончания расследования.
Что сделали FirstVDS и ISPsystem
Сразу после обнаружения атаки FirstVDS закрыл внешний доступ к системе управления виртуализацией, через которую она шла, и заблокировал в своей сети адрес сервера злоумышленников. 18 октября в 15:25 по Москве провайдер разослал дополнительные уведомления владельцам серверов на узлах, где нашли признаки возможной компрометации. Утром 19 октября FirstVDS добавил, что ночью разработчик выпустил ещё одно исправление и его уже поставили. Но уязвимость закрыта не полностью: открывать доступ к панели вендор не рекомендует и готовит следующие патчи, а до их выхода доступ остаётся закрытым.
В списке изменений VMmanager 18 октября появились версии 2026.09.1-3 и 2026.05.2-7, у обеих одна строка: «Исправление ошибок безопасности». Номер CVE и технические подробности уязвимости пока не раскрыты.
Если у вас своя площадка на VMmanager 6, обновитесь до этих версий или новее и не держите панель открытой на весь интернет: пускайте к ней только с доверенных адресов или через VPN.
Пришло уведомление: что делать по порядку
Главный риск сейчас не в самом сервере, а в том, что украденными паролями и ключами воспользуются. Поэтому менять их надо как можно скорее, в таком порядке:
- Криптокошельки в первую очередь: переведите средства на новые кошельки, созданные на другом, чистом устройстве.
- Смените все пароли, SSH-ключи, API-ключи и токены, которые лежали на сервере: root и пользователей, базы данных, панели управления сайтами, почту, облачные сервисы, CI/CD, платёжные системы. Пройдитесь по .env, wp-config.php и другим конфигам, где записаны пароли от баз и внешних API.
- Отзовите старые ключи, а не просто выпустите новые: в облачных консолях, GitHub и GitLab, у платёжных провайдеров. Иначе старый токен продолжит работать.
- Перевыпустите то, чем пользуется сам сервер: ключи хоста SSH, приватные ключи TLS-сертификатов сайтов, ключи шифрования бэкапов. Они тоже лежали на диске.
- Проверьте журналы входов на сервере и в сервисах, ключи от которых на нём хранились: не было ли входов с незнакомых адресов после 17 октября.
- Если злоумышленник мог успеть войти до смены паролей, проверьте ~/.ssh/authorized_keys, новых пользователей, задания cron и службы systemd.
- Если на сервере были персональные данные ваших клиентов, обсудите с юристом, нужно ли уведомлять Роскомнадзор.
Для журналов, ключей, cron и служб хватит нескольких команд:
# входы по SSH с 17 октября
sudo journalctl -u ssh -u sshd --since "2026-10-17" | grep -i accepted
last -a | head -50
# чужие ключи и пользователи с UID 0 или обычные
sudo cat /root/.ssh/authorized_keys; cat ~/.ssh/authorized_keys
awk -F: '$3==0 || $3>=1000 {print $1, $3, $7}' /etc/passwd
# cron всех пользователей
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
# службы и задания, изменённые после 17 октября
sudo find /etc/systemd/system /etc/cron* -newermt "2026-10-17" -type f
Ключи хоста SSH перевыпускаются так. Текущую сессию не закрывайте, пока не проверите вход в новом окне. При следующем подключении клиент предупредит о смене ключа, старую запись из known_hosts убирают через ssh-keygen -R.
sudo rm /etc/ssh/ssh_host_* sudo ssh-keygen -A sudo systemctl restart ssh # в RHEL-подобных системах: sshd # на своём компьютере ssh-keygen -R 203.0.113.10
Что это значит для выбора хостинга
Атака шла через панель управления провайдера, а не через сайт или сервис клиента. Здесь не помогают ни свежий WordPress, ни fail2ban: всё, что лежит на диске VPS открытым текстом, можно прочитать с узла виртуализации. От такого чтения защищает шифрование диска внутри VPS (LUKS): снаружи видны только зашифрованные блоки. Правда, после каждой перезагрузки диск придётся открывать вручную через консоль. Токены к облакам и CI стоит выдавать с минимальными правами и коротким сроком жизни, тогда утечка обойдётся дешевле.
Бэкапы и ключи от них лучше держать у другого провайдера. Мысль та же, что в заметках про инцидент в дата-центре Яндекса в Сасово и резервные ЦОДы: одна площадка рано или поздно подводит, поэтому сервисы стоит раскладывать по нескольким зонам, а копии хранить в другом регионе или у другого провайдера.
Если вы сейчас выбираете VPS, в том числе у FirstVDS, смотрите не только на цену, но и на то, как провайдер ведёт себя во время инцидента: быстро ли сообщает, даёт ли список затронутых серверов и понятную инструкцию. Как выбирать между shared-хостингом, VPS и выделенным сервером, я разбирал в отдельной заметке.
Если от FirstVDS пришло уведомление, считайте скомпрометированным всё, что лежало на сервере, и начинайте с кошельков, паролей и отзыва токенов. Если уведомления нет, загляните в личный кабинет ещё раз в ближайшие дни: расследование не закончено, а патчи для VMmanager 6 ещё выходят.
