С 20:57 UTC 28 августа до 06:10 UTC 30 августа 2026 года злоумышленники смогли подменить сетевой маршрут к инфраструктуре обновлений Virtualizor и раздать вредоносный пакет части клиентов. Для тех, кто управляет VPS, это неприятный, но полезный сигнал: атака на Virtualizor показала, что компрометация цепочки обновлений бывает не только через взлом репозитория или CI, но и через саму маршрутизацию трафика.
Об инциденте сообщает BleepingComputer со ссылкой на срочное уведомление Softaculous, разработчика Virtualizor. Речь идет о legacy-панели для управления VPS, которую хостинг-провайдеры используют для создания, продажи и администрирования виртуальных серверов. По данным компании, атакующий перехватил BGP-маршрутизацию для блока IP-адресов, размещенных у Hetzner, из-за чего запросы к системе обновлений и клиентскому биллинговому порталу начали уходить не туда, куда ожидали администраторы и клиенты, а на подконтрольные злоумышленнику узлы.
Механика здесь важнее громких формулировок. BGP hijacking работает просто и оттого особенно неприятно: оператор сети или злоумышленник объявляет ложный маршрут до чужого диапазона IP-адресов, а часть интернета принимает его как предпочтительный. После этого трафик можно не только перехватывать, но и менять по пути. В истории с Virtualizor результат оказался максимально практичным для атакующих: вместо легитимного обновления некоторые серверы получили вредоносный пакет. Softaculous подчеркивает, что пострадало не все пользовательское сообщество, а лишь небольшое число установок, которые проверяли обновления в период, когда трафик уже был перенаправлен.
Ключевая проблема для расследования в том, что у вендора нет полных журналов по этим запросам. И это логично: когда трафик ушел на сторону атакующего, он вышел из зоны видимости самой Softaculous. Для администраторов это плохая новость, потому что рассчитывать на аккуратный централизованный список всех затронутых узлов не приходится. Компания рекомендует вручную проверить наличие сервиса /etc/systemd/system/java-jre-update.service. Если он найден, дальше начинается обычная, но трудоемкая аварийная рутина: ротация и ограничение API-учетных данных, аудит несанкционированных SSH-ключей, проверка новых аккаунтов, планировщиков задач и подозрительных исходящих соединений. Для тех, кто в это окно входил в клиентскую зону Softaculous или вводил платежные данные, совет тоже без сюрпризов: сменить пароль, посмотреть активность аккаунта и следить за операциями по карте.
Самый неприятный вывод из этой истории в том, что атака на Virtualizor не опиралась на экзотическую уязвимость в коде панели. Внутри корпоративных ИБ-команд до сих пор любят обсуждать supply chain как историю про npm-пакеты, зараженные библиотеки и скомпрометированные CI/CD-конвейеры. Но здесь цепочка поставки софта была пробита на сетевом уровне. Для хостингов и сервис-провайдеров это особенно чувствительно: у них обновления часто завязаны на автоматические процессы, а сама инфраструктура живет на множестве внешних зависимостей, от дата-центров до провайдеров аплинка. Если доверие к каналу доставки обновления строится в основном на том, что запрос ушел на «правильный» адрес, этого больше недостаточно.
Softaculous уже сообщила, что маршрутизация восстановлена, мошеннический сертификат отправлен на отзыв, а 1 сентября выпущена новая версия Virtualizor 3.2.9.9. В ней появился инструмент Security Analyzer в административной панели. Параллельно компания пообещала внедрить криптографическую подпись всех программных пакетов и перенести сервисы на более надежную инфраструктуру. Это, пожалуй, главный кусок всей новости. Если подпись пакетов появляется после инцидента, значит до этого доверенная доставка обновлений была устроена слабее, чем того требует продукт такого класса. Для панели, которая стоит на узле управления VPS, это не просто техническая оплошность, а архитектурный долг с прямым операционным риском.
Для русскоязычной IT-аудитории здесь есть несколько практических выводов. Первый: если у вас в проде есть устаревшие панели и «проверенные годами» инструменты, это не аргумент в их пользу, а повод заново проверить модель доверия. Legacy-софт часто живет именно потому, что «и так работает», но инциденты обычно вскрывают не один баг, а слой старых допущений: не подписанные обновления, лишние права у служебных аккаунтов, слабая сегментация, привычка тянуть обновления напрямую снаружи без промежуточной валидации. Второй: BGP hijacking остается не академической темой из учебника по сетям, а рабочим инструментом атаки. Если бизнес зависит от внешних обновлений, стоит хотя бы задать себе неприятный вопрос: что именно на узле проверяет подлинность пакета, кроме TLS и имени хоста? Третий: после любого инцидента с обновлениями надо искать не только файл-индикатор компрометации, но и постэксплуатацию. Если вредоносный пакет успел выполниться, он мог оставить доступ через ключи, systemd-сервисы, cron или фоновые соединения.
Softaculous отдельно уточняет, что на данный момент признаков компрометации других ее продуктов нет, а расследование продолжается. Формулировка осторожная и правильная: в первые дни после сетевой атаки излишняя уверенность обычно только мешает. Но уже сейчас история выглядит как еще один довод в пользу обязательной подписи обновлений, независимой верификации пакетов и более жесткого контроля маршрутизации критичных сервисов. Хостинговый рынок давно привык продавать отказоустойчивость как товар, а вот доверие к каналу обновления по-прежнему слишком часто считается чем-то само собой разумеющимся. После этой истории такой подход выглядит дорого даже для тех, кого она формально не задела.