Сайт открывается, заказы поступают, мониторинг не показывает сбоев. Однако это ещё не подтверждает сохранность данных. При атаке на инфраструктуру FirstVDS информацию копировали с дисков виртуальных серверов, не запуская вредоносную программу внутри самих виртуальных машин.

FirstVDS: доступность сервера не гарантирует сохранность данных

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

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

Виртуальные машины продолжали работать. Поэтому отсутствие следов внутри гостевой системы не исключало копирование данных. Инцидент затронул часть инфраструктуры, а не все серверы провайдера.

FirstVDS закрыл внешний доступ к управлению виртуализацией и заблокировал адрес получателя данных. Владельцам выявленных пострадавших серверов направили уведомления на почту и в личный кабинет.

Как данные могли покинуть работающую виртуальную машину

Диск читали со стороны узла виртуализации. Для этого не требовался обычный вход в гостевую ОС.

Что уточнил FirstVDS после первых публикаций

В обновлении от 21 октября компания сообщила о завершении собственного технического разбора. Уведомления отправляли в три этапа; после дополнительной проверки новых затронутых узлов не ожидали. На части узлов нашли скрытые службы, способные восстановить доступ атакующих. Это сообщение касается инфраструктуры провайдера и само по себе не доказывает наличие таких служб в каждой клиентской ВМ.

Тогда же FirstVDS сообщил со ссылкой на вендора о закрытии уязвимости. Панели решили оставить недоступными на время восстановления и проверок. Обновление от 23 октября предупреждает о замедлении операций управления и сообщает, что большинство операций VMmanager и DNSmanager пока выполняются через поддержку.

Полный объём скопированной информации провайдер подтвердить не смог. Получателям уведомлений предложено считать скомпрометированными все данные соответствующего сервера. Эти сведения приведены по официальному сообщению с обновлениями по 23 октября, а не как обещание текущей доступности услуг.

Какие доступы проверить в первую очередь

Ниже — практический порядок проверки для владельца сайта на основе рекомендаций провайдера. Начните с перечня систем, к которым сервер имел доступ. Смена одного пароля root не завершает эту работу.

Где проверить	Какие доступы учесть	Как зафиксировать результат
Сервер и панель сайта	Учётные записи, SSH-ключи, администраторы	Старые доступы отключены, новые проверены
Приложение и база	Пароли БД и секреты в конфигурациях	Настройки обновлены, сайт подключается к БД
Почта и интеграции	SMTP, API и облачные токены	Новые значения применены, прежние отозваны
Развёртывание	CI/CD, репозитории, сервисные учётные записи	Обновлены зависимости, проверено развёртывание

Выпуск нового токена не отменяет старый автоматически во всех сервисах. Проверяйте отзыв в системе, которая выдала доступ. Для SSH также нужно убрать разрешение на старый публичный ключ на тех машинах, куда соответствующий приватный ключ позволял входить.

Если на сервере хранились данные криптокошельков, FirstVDS рекомендует в первую очередь перевести средства на новые кошельки, созданные на чистом устройстве.

Замена доступов: учёт, обновление, отзыв и проверка

Ротация завершена, когда приложение работает с новыми реквизитами, а старые больше не дают доступа.

Что искать в журналах и настройках

Провайдер рекомендует проверить входы начиная с 17 октября — как на сервере, так и во внешних сервисах, чьи ключи на нём хранились. Отдельного внимания требуют неизвестные пользователи, записи в ~/.ssh/authorized_keys, задания cron и службы systemd.

Сопоставляйте изменения с действиями своей команды. Незнакомое название ещё не доказывает заражение: перед удалением выясните назначение объекта и сохраните сведения для разбора. Для проверки самого сайта на Битрикс пригодится наш материал о признаках взлома и поиске вредоносного кода.

Две отдельные проверки: утечка данных и последующий вход

Журналы помогают искать использование похищенных доступов. Они не обязаны показывать первоначальное чтение диска со стороны хостинга.

Если на сервере находились персональные данные клиентов, FirstVDS также советует обсудить с юристом необходимость уведомления Роскомнадзора. Само наличие сайта не позволяет определить эту обязанность без разбора обстоятельств.

Как не потерять часть работы

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

Возврат к резервной копии не отзывает уже похищенные ключи. Если решено перенести приложение на другой сервер, включите смену секретов в план переноса. Технические работы и сроки реакции стоит заранее закрепить в регламенте поддержки сайта.

Источники

FirstVDS: сообщение об инциденте и обновления по 23 октября 2026 года.
«Хакер»: компания FirstVDS сообщила о взломе, 19 октября 2026 года.

Нужно проверить доступы к вашему сайту?

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

Написать в SolverWeb ↗