Атака на VMmanager 6: 0-day HTTP Request Smuggling и 11 хотфиксов 2026

Что произошло, почему это важно и что взять в работу.

Публично доступные панели виртуализации оказались входной точкой для 0-day — теперь закрытие пользовательских ISO, SSH-доступа и проверка версии nginx стали обязательной гигиеной для хостинга и DevOps.

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Двое суток тишины, потом двадцать обращений за день

12 октября 2026 года в инфраструктурах нескольких хостинг-провайдеров появились первые следы чужого присутствия. Никто тогда не связал их между собой. Через двое суток, 14 октября в 00:40 МСК, в техподдержку ISPsystem написал первый клиент: на серверах под управлением VMmanager 6 Hosting происходит что-то постороннее.

Дальше события пошли плотно. 14 октября в 19:00 выходят экстренные хотфиксы 2026.05.2–5 и 2026.09.1–1. 15 октября похожий патч 2026.09.1–1 получает DCImanager. 17 октября утром начинается вторая волна, к вечеру в поддержке уже около двадцати обращений. 19 октября в 16:00 становится понятна причина: ранее неизвестная 0-day уязвимость, контрабанда HTTP-запросов (HTTP Request Smuggling). 21 октября в 19:00 «Лаборатория Касперского» передаёт провайдерам бесплатный KVRT для чистки. 22 октября в 21:30 выходят финальные хотфиксы 2026.05.2–11 и 2026.09.1–7.

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

Как атаковали: две уязвимости подряд, вторая вместо первой

Начали с ISO-образа. Ошибка в нём давала вход с первичного пользовательского доступа. Расшифруем: чтобы добраться до платформы, злоумышленнику достаточно было купить виртуальную машину у провайдера. Не нужен был ни договор, ни доступ к админке, ни знакомство с сетевым периметром. Купил ВМ, дальше пошёл внутрь.

Уязвимость в ISO верифицировали в рамках Bug Bounty 9 октября. Патч планировали на 15 октября, потому что требовались архитектурные доработки. Не успели: релиз заменили экстренным хотфиксом 14 октября, собранным из исправлений будущей версии, но без части превентивных доработок.

Это сработало ровно наполовину. По логам атакованных систем 17 октября стало видно: хотфикс закрыл то, что должен был закрыть, а злоумышленник зашёл с другой стороны. Через вторую уязвимость, о которой не знал никто, включая вендора.

19 октября в 16:00 МСК механику описали. В систему отправлялся HTTP-запрос на установку websocket-соединения, но с телом. С точки зрения RFC поведение клиента не рекомендуется. Nginx такие запросы пропускает. Дальше происходит вот что: сервис, к которому обращаются, запрос отвергает, но тело не вычитывает. А поскольку запрос шёл с keep-alive, это тело читается как следующий запрос.

19.10.2026 в 16:00 (МСК) в ходе расследования мы установили, что злоумышленник проникал на серверы с использованием контрабанды HTTP‑запросов (HTTP Request Smuggling).

Тонкость, из-за которой всё и сломалось. Внутри docker-сети службы помечают внутренние запросы служебным HTTP-заголовком, снаружи такой заголовок не принимается. Фронтенд на nginx его не пропускает. Но второй запрос nginx воспринимал как тело первого, поэтому не анализировал и не менял его. Служебный заголовок проходил насквозь. Злоумышленник выполнял запрос внутри системы с административными привилегиями.

Для обычного proxy_pass вендор ставил Connection: close, и такой фокус не проходил. Для websocket так сделать нельзя, соединение должно жить. Отсюда и щель.

Почему это важнее, чем одна панель

VMmanager 6 Hosting живёт в открытом контуре. Не в том смысле, что у неё есть выход в интернет, а в том, что её сервисы висят на белых IP-адресах и торчат наружу. Иначе провайдер не продаст ни одной машины. Клиент должен зайти в панель, заказать ВМ, получить доступ, поставить себе что угодно.

У Enterprise-сегмента модель другая. Там инфраструктуру можно закупорить внутри корпоративного периметра, и снаружи её не видно вообще. Поверхность атаки измеряется десятками адресов, а не тысячами. Разница принципиальная, и модели угроз для этих двух сценариев не пересекаются.

Отсюда практический вывод для каждого, кто держит хостинг или управляет парком ВМ. Публичная панель виртуализации это входная точка уровня «ядро продукта». Она стоит первой в списке того, что смотрят снаружи, потому что через неё проходят все: биллинг, заказ, управление, продление. Компрометация одной такой панели даёт доступ к инфраструктуре провайдера, а через неё к клиентским машинам.

Что делал вендор, пока искал причину

Между 14 и 19 октября ISPsystem резала функционал платформы, чтобы сузить злоумышленнику пространство для манёвра. Закрыли выдачу SSH-доступа. Запретили администраторам запускать скрипты для узлов и ВМ. Ограничили запуск и выполнение скриптов внутри платформы. Провайдерам дали рекомендации по закрытию инфраструктур.

По сути это карантин. Функциональность, которая нужна в работе каждый день, выключили, потому что через неё можно двигаться внутри продукта. Вернули поэтапно, хотфиксами от 20 по 22 октября. Нумерация говорит сама за себя: ветка 2026.05.2 дошла до одиннадцатого хотфикса, ветка 2026.09.1 до седьмого. Одиннадцать итераций за восемь дней.

21 октября в 19:00 «Лаборатория Касперского» предоставила бесплатный KVRT провайдерам, чьи инфраструктуры пострадали.

В поиске и устранении следов атакующих и индикаторов компрометации свою помощь нам предложила «Лаборатория Касперского» — и мы его приняли.

Отдельная история про nginx. Директиву client_body_early_read добавили в версии 1.31.5 от 2 сентября 2026 года. Она блокирует подобные запросы и для HTTP/1.1, и для HTTP/2. В stable-ветке 1.30.6 её нет. То есть на «стабильной» сборке вы эту дыру настройкой не закроете, придётся либо переезжать на мейнлайн, либо решать на другом уровне.

В NGINX, начиная с версии 1.31.5 от 2 сентября 2026 года, появилась директива client_body_early_read, позволяющая легко и удобно настраивать блокировку подобных запросов как для HTTP/1.1, так и для HTTP/2.

Вендор сам оговаривается: особенность nginx не снимает с него ответственности за инцидент. Правильная позиция. Контрабанда запросов через websocket-апгрейд известна давно, и продукт, который выставляет наружу фронтенд и не валидирует служебный заголовок на своей стороне, уязвим независимо от того, как ведёт себя прокси.

Таблица: факт → что это значит

Что взять в работу на этой неделе

Порядок неслучайный. Первое: проверить, какие версии VMmanager 6 и DCImanager 6 стоят в вашем контуре, и поднять их до 2026.05.2–11 и 2026.09.1–7 соответственно. Промежуточные хотфиксы не заменяют финальные, цепочка из одиннадцати патчей собиралась по кусочкам.

Второе: закрыть загрузку пользовательских ISO там, где она вам не критична. Это прямой и подтверждённый вход. Для скомпрометированных инфраструктур рекомендация была именно такой, но и для чистых лишняя дверь наружу ни к чему.

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

Четвёртое: версия nginx. Мейнлайн 1.31.5 и выше с директивой client_body_early_read. Если остаётесь на 1.30.6, дыру прикрывает не настройка, а архитектура: что ещё стоит перед сервисом, как валидируются служебные заголовки, не доверяет ли бэкенд заголовку просто по факту его наличия.

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

Что здесь остаётся нерешённым

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

Вторая развилка: зависимость от чужого прокси. Если уязвимость эксплуатируется через поведение nginx, который вы не контролируете, а фикс живёт в мейнлайн-ветке, а не в stable, вы оказываетесь между двумя неудобными решениями. Либо переезд на мейнлайн с его темпом обновлений, либо собственная валидация на уровне приложения. Без замеров и без тестов на своём стенде я не возьмусь обещать, что второй вариант закроет всё. Он точно дешевле, чем инцидент.

Третье: темп. Восемь дней, одиннадцать хотфиксов, карантин функционала. Для вендора это быстро. Для провайдера, у которого в это время не работает выдача SSH, это восемь дней ручной работы поддержки и недовольных клиентов. Считать надо обе стороны.

Вердикт

Это не «неприятный инцидент в чужой нише». Это демонстрация того, как выглядит атака на отрасль, где публичный доступ не опция, а бизнес-модель. Купить ВМ за пару сотен рублей и оттуда пойти внутрь платформы может кто угодно. Никакого предварительного доступа к периметру не требовалось.

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

И да, отдельная ремарка для тех, кто держит VMmanager в закрытом корпоративном контуре. Ваша модель угроз мягче, но патчи от этого не становятся необязательными. Общая архитектура продукта одна, и ошибка в ISO-образе от периметра не зависит.