Новости

23.10.2026

Уязвимость VMmanager 6: что случилось и как защитить свои данные

17 октября в VMmanager 6 — панели управления виртуализацией — была эксплуатирована уязвимость, через которую злоумышленники проникли в часть нашей инфраструктуры. Ниже о том, что известно на данный момент и какие меры необходимо принять.

Как проходила атака

На части узлов была запущена вредоносная программа, которая читала и копировала данные. Она не изменяла содержимое дисков и не запускалась внутри клиентских серверов. Поэтому серверы продолжали работать штатно, а в их операционных системах могло не остаться следов работы самой программы. Какие данные могли оказаться под угрозой компрометации:

учётные данные и токены, включая SSH- и API- ключи;
файлы конфигурации и журнал выполненных команд;
криптокошельки и seed-фразы;
личные файлы на сервере.

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

Если уведомления нет — это значит, что следов атаки на ваших узлах мы не нашли. Для профилактики проверьте журналы входов и файл ~/.ssh/authorized_keys, а при подозрительной активности сообщите нам через тикет. Доступы к важным сервисам и криптокошелькам лучше сменить.

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

Что делать, если вы получили уведомление

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

Обезопасьте данные криптокошельков в первую очередь. Заведите новый кошелёк на другом, заведомо безопасном устройстве и сразу переместите в него средства. Отзовите ключи бирж.
Смените любые доступы, которые лежали на этом сервере — от учётной записи root и обычных пользователей до баз данных, сайтов, почтовых ящиков, облака, CI/CD-систем и платёжных сервисов. Важно не только сменить их, но и отозвать: новый ключ не защитит, пока старый не деактивирован.
Проверьте, кто и откуда входил на сервер и в связанные с ним сервисы начиная с 17 октября — ищите незнакомые адреса. Дополнительно просмотрите ~/.ssh/authorized_keys, актуальных пользователей, задания cron и запущенные службы systemd на предмет лишнего.
Если на сервере обрабатывались персональные данные, проконсультируйтесь с юристом о применимых требованиях законодательства и необходимости уведомления Роскомнадзора.

Разбор инцидента продолжается. По мере появления новой информации мы будем дополнять эту новость.

Поддержка работает в штатном режиме, но время ответа может быть дольше обычного. Мы на связи через тикеты в личном кабинете и в чате на сайте.