33-часовой BGP-угон трафика у Softaculous оказался не академической страшилкой про маршрутизацию, а вполне прикладной проблемой: часть клиентов могла отдать злоумышленникам логины, пароли и даже получить вредоносное обновление Virtualizor. Для русскоязычной IT-аудитории история неприятно знакомая: если панель управления хостингом или канал обновлений завязаны на доверие к сети, одного сбоя в маршрутах хватает, чтобы инцидент быстро переехал из NOC в production.
Инцидент длился примерно с 20:57 UTC 28 августа до утра 30 августа, сообщает The Register. По данным самой Softaculous, посторонняя сеть начала анонсировать более специфичный диапазон IP-адресов Hetzner, через который обслуживалась часть систем вендора. В результате трафик, предназначенный Softaculous, уводился на сервер злоумышленника. Под удар попали как минимум endpoint обновлений Virtualizor, а также клиентская и биллинговая площадка Softaculous. Маршрут не держался идеально ровно, а «флапал», но это не сделало атаку менее опасной: вендор оценивает, что во время активных фаз у конкретного сервера была примерно 72-процентная вероятность оказаться в сети, которая принимала hijacked route.
Технически схема выглядела почти образцово-показательной. В BGP более специфичный префикс обычно выигрывает у менее специфичного, если его принимают провайдеры по пути. Этим злоумышленник и воспользовался. Хуже другое: Softaculous утверждает, что атакующая сторона смогла получить валидный TLS-сертификат Let’s Encrypt, потому что автоматическая проверка владения доменом тоже прошла через перехваченный маршрут. То есть часть пользователей не увидела привычного красного флага в виде предупреждения о сертификате. Для администраторов это важная деталь: замочек в браузере в такой ситуации не спасает, если контроль над маршрутом на время перехвачен, а в цепочке доверия слишком много автоматизма.
Что именно пошло не так
Первую волну Softaculous заметила и сообщила Hetzner около 08:50 UTC 29 августа. Хостер начал анонсировать тот же более специфичный диапазон адресов напрямую, и примерно на 11 часов наблюдаемое отклонение трафика почти сошло на нет. Но около 20:00 UTC 29 августа несанкционированный анонс вернулся и запустил вторую волну, которая продлилась около десяти часов. Только между 05:50 и 06:10 UTC 30 августа маршрут окончательно отозвали, после чего глобальная маршрутизация нормализовалась. Сам по себе этот таймлайн выглядит как напоминание о неудобной правде интернета: даже если проблему заметили быстро, вычищать последствия BGP-инцидента по всей сети все еще долго, шумно и местами хаотично.
Самое неприятное последствие связано не с клиентским кабинетом, а с цепочкой обновлений. Softaculous признала, что нескольким установкам Virtualizor был отдан вредоносный пакет обновления. Причина звучит жестко и по делу: клиент обновлений продукта не проверял пакеты криптографически, поэтому модифицированный пакет не был бы отвергнут только на основании подмены. Иными словами, доставка обновления в этой схеме доверяла не подписи артефакта, а факту, что пакет якобы пришел «оттуда, откуда надо». В 2026 году это уже не просто архитектурный долг, а почти приглашение к инциденту, особенно для систем, которые управляют VPS и имеют высокий уровень привилегий.
Проблема для операторов в том, что Softaculous не может назвать исчерпывающий список пострадавших инсталляций: загрузки, ушедшие через сервер злоумышленника, не попали в журналы вендора. Поэтому рекомендация предельно прагматичная: всем операторам Virtualizor считать свои серверы входящими в зону проверки, хотя не считать их автоматически скомпрометированными. В качестве явного индикатора компрометации назван systemd-юнит /etc/systemd/system/java-jre-update.service. Если он найден, удалять его сразу не советуют: сначала лучше связаться с вендором и сохранить артефакты для расследования. Для остальных продуктов компании, включая Backuply, Softaculous, SitePad и Webuzo, подтвержденных вредоносных пакетов на момент публикации не было, но расследование продолжается.
Что делать клиентам и какой вывод для отрасли
Практические действия со стороны клиентов выглядят ожидаемо, но список длинный не просто так. Всем, кто входил в клиентскую зону Softaculous в окно инцидента, советуют срочно менять пароль и особенно проверять его повторное использование в других сервисах. Тем, кто вводил данные банковской карты, рекомендуют просмотреть выписки: сама Softaculous пишет, что не обрабатывает карты на своих серверах и использует платежные шлюзы, но сессия могла быть перехвачена до перенаправления к ним. Операторам Virtualizor дополнительно предлагают ротировать и ограничить API-учетные данные, проверить неизвестные SSH-ключи и учетные записи, пересмотреть планировщики задач и исходящие соединения, а также перевыпустить API-ключи клиентской зоны. Отдельно компания аннулирует клиентские сессии, созданные во время инцидента.
Для разработчиков и владельцев инфраструктурных продуктов здесь урок неприятный, но полезный. BGP-угон трафика в этой истории сработал не потому, что интернет внезапно стал небезопасным, а потому, что поверх уже известной сетевой хрупкости оказались недозащищены несколько критичных слоев: обновления без криптографической проверки, автоматическое доверие к TLS в момент маршрутизационной аномалии и высокая ценность самой панели управления инфраструктурой. Если ваш продукт умеет обновлять себя с правами root или управляет чужими серверами, подпись пакетов, жесткая валидация артефактов и процедура аварийной ротации ключей должны быть обязательной частью базовой инженерии, а не пунктом в backlog «на потом».
У Softaculous пока нет публичной цифры, сколько именно клиентов отдали учетные данные или скачали вредоносное обновление; компания говорит лишь о «нескольких серверах», а не о массовом заражении всей базы Virtualizor. Но в этом и главный нерв истории: даже ограниченный BGP-угон трафика способен быстро пробить сразу две самые дорогие зоны доверия в инфраструктурном софте — логин пользователей и механизм обновлений. Для отрасли это плохая новость, но довольно ясная: следующая проверка зрелости security-программы будет не на слайдах про zero trust, а на вопросе, что именно произойдет, если ваш апдейт-сервер на несколько часов «переедет» к чужому AS.