Атака на VMmanager 6 — хронология инцидента, разбор использовавшихся уязвимостей и ситуация сейчас

Привет, Хабр. Наверняка многие из вас уже слышали о недавнем инциденте безопасности, затронувшем платформу управления виртуализацией VMmanager 6. Ситуация вызвала активные обсуждения в профессиональном сообществе, и мы считаем важным открыто поделиться техническими деталями произошедшего.

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

Как все началось и что именно произошло

14.10.2026 в 00:40 (МСК) в нашу службу технической поддержки поступило обращение от одного из хостинг-провайдеров — в его инфраструктуре была обнаружена подозрительная активность на серверах под управлением VMmanager 6 Hosting.

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

По информации от провайдеров мы выдвинули предположение, что злоумышленник проник в инфраструктуру через уязвимость в ISO-образе. Подобная ошибка предполагает наличие первичного пользовательского доступа, который можно получить, просто купив виртуальную машину у хостинг-провайдера. Эта уязвимость , была верифицирована в рамках программы Bug Bounty 9 октября, и команда работала над ее исправлением. Но поскольку это требовало определенных архитектурных доработок, поэтому релиз новой версии платформы был запланирован на 15 октября.

14.10.2026 в 19:00 (МСК) для экстренного закрытия уязвимостей вместо запланированного патча мы выпустили два хотфикса — 2026.05.2-5 и 2026.09.1-1, основанные на исправлениях, запланированных для новой версии. Чтобы ускорить выпуск, мы не стали включать в этот хотфикс ряд превентивных архитектурных доработок, которые планировали к релизу 15 октября — они вошли в следующие хотфиксы. Сразу после выпуска хотфиксов мы связались с заказчиками через нашу техническую поддержку —  сообщили, что их надо немедленно установить и дали еще ряд рекомендаций по защите инфраструктур, в том числе крайне рекомендавали закрыть возможность загрузки пользователями своих ISO для уже скомпрометированных инфраструктур. Поскольку VMmanager и DCImanager имеют ряд общих сервисов, схожий патч 2026.09.1-1 был собран и применён для DCImanager 15.10.2026.

В отличие от Enterprise-сегмента, где инфраструктуру можно полностью изолировать внутри закрытого корпоративного периметра, бизнес-модель хостинг-провайдеров требует максимальной публичной доступности. Из-за этого хостинг-провайдеры, как правило, эксплуатируют платформу в открытом контуре. Здесь важно уточнить: для хостинг-провайдера «открытый контур» — это не просто наличие доступа в интернет, а публично доступные сервисы на белых IP-адресах. Именно белые IP-адреса и выставленные наружу сервисы кратно увеличивают поверхность атаки, которая включает не только саму платформу, но и окружающую инфраструктуру. У инфраструктурных клиентов «открытый контур» обычно означает лишь доступ в интернет. Поэтому модели угроз для этих двух сценариев принципиально различаются.

Утром 17.10.2026 (МСК) началась новая волна атак. Количество обращений в нашу техподдержку увеличивалось по нарастающей в течение дня, и к вечеру 17 октября их было уже около 20. В ходе изучения журналов атакованных на этом этапе систем мы поняли две вещи:

• выпущенный ранее хотфикс решил поставленную перед ним задачу;

• злоумышленник начал дополнительно эксплуатировать другую уязвимость

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

18.10.2026 в 4:00 (МСК) были выпущены хотфиксы 2026.05.2-6 и 2026.09.1-2. Мы намеренно ограничили часть функционала, в том числе запуск и выполнение скриптов внутри платформы. Это позволяло «парализовать» злоумышленника, однако мы понимали, что первопричина инцидента пока не найдена, и продолжали вести расследование.

18.10.2026 в 18:00 (МСК) были выпущены хотфиксы 2026.05.2-7 и 2026.09.1-3 с закрытием дополнительных потенциально возможных путей перемещения внутри продукта.

19.10.2026 были выпущены обновления безопасности для DCImanager 6 — 2026.09.1-3 и 2026.09.1-4. Поскольку платформа имеет схожую архитектуру с VMmanager 6, в рамках реагирования на инцидент мы начали защищать и ее.

19.10.2026 в 16:00 (МСК) в ходе расследования мы установили, что злоумышленник проникал на серверы с использованием контрабанды HTTP-запросов (HTTP Request Smuggling). Для этого использовалась ранее неизвестная 0-day уязвимость в нашем сервисе, а особенность nginx пропускать такие запросы делала ее эксплуатацию возможной. В систему отправлялся HTTP-запрос на установку websocket-соединения с телом. По RFC такое поведение со стороны клиента не рекомендуется, nginx пропускает подобные запросы, и это открыло возможность использования контрабанды HTTP-запросов.

В NGINX, начиная с версии 1.31.5 от 2 сентября 2026 года, появилась директива client_body_early_read, позволяющая легко и удобно настраивать блокировку подобных запросов как для HTTP/1.1, так и для HTTP/2 (к счастью, HTTP/3 мы не используем). К сожалению, в stable-версии nginx на текущий момент (1.30.6) эта директива еще не поддерживается. Безусловно, найденная особенность работы nginx не снимает с нас ответственности за возникновение инцидента, однако мы крайне рекомендуем учитывать ее, если вы используете это решение в своей инфраструктуре.

Работает это следующим образом:

Сервис, к которому обращается злоумышленник, запрос отвергает, но при этом не вычитывает его тело, а поскольку запрос содержит keep-alive, читает полученное тело как новый запрос. Для обычных запросов при передаче их из nginx в сервис (proxy_pass) мы со своей стороны использовали дополнительные Connection: close, что не позволяет обманывать систему подобным образом, но для websocket этого делать нельзя.

Это и позволило злоумышленнику выполнить запрос внутри системы с административными привилегиями. Внутри сети docker наши службы помечают внутренние запросы специальным HTTP-заголовком, который снаружи не принимается (nginx, используемый как фронтенд, этот заголовок не пропускает). Но из-за того, что nginx второй запрос воспринимал как тело первого, он никак не анализировал и не менял его.

19.10.2026 в 21:00 (МСК) были выпущены хотфиксы 2026.05.2-8 и 2026.09.1-4 с исправлением обнаруженной контрабанды HTTP-запросов (HTTP Request Smuggling), при этом блокировка части функционала сохранялась, поскольку злоумышленник все еще оставался внутри платформы.

20.10.2026 в 4:00 (МСК) были выпущены хотфиксы 2026.05.2-9 и 2026.09.1-5: возвращены веб-сокеты, которые ранее ограничил хотфикс против HTTP Request Smuggling, а также выпущен более аккуратный фикс основной уязвимости, не затрагивавший основную функциональность платформы.

Параллельно мы занимались зачисткой инфраструктур — искали вредоносные файлы, бэкдоры и закрепления и значительную часть из них находили и удаляли сами. 

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

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

20.10.2026 в 21:30 (МСК) выпущены хотфиксы 2026.05.2-10 и 2026.09.1-6 с доработкой архитектуры и возвратом ещё части намеренно заблокированного функционала. Добавлена автоматическая блокировка известных «закладок» злоумышленника. Также был выпущен фикс для DCImanager — 2026.09.1-5.

21.10.2026 в 19:00 (МСК) на основе анализа данных хостинг-провайдеров «Лаборатория Касперского» предоставила бесплатный инструмент Kaspersky Virus Removal Tool (KVRT) для дополнительного сканирования инфраструктур и выявления оставшихся вредоносных объектов, включая бинарные файлы и другие следы атакующих. После того, как это показало свою эффективность, мы предложили его всем, кого затронул инцидент.

22.10.2026 в 21:30 (МСК) мы выпустили фиксы 2026.05.2-11 и 2026.09.1-7 с дополнительными механизмами защиты платформы от потенциальных атак и стабилизационными улучшениями уже выпущенных хотфиксов. А параллельно продолжили анализировать скомпрометированные инфраструктуры, искать бэкдоры и аномалии.

23.10.2026 были выпущены обновления безопасности для всех продуктов экосистемы: 

• VMmanager 6 — stable v2026.05.2-12, regular v2026.09.1-8;

• DCImanager 6 — stable v2026.09.2-2, regular v2026.09.1-6;

• BILLmanager 6 — stable v6.154.5, regular v6.157.3;

• DNSmanager 6 — v6.5.2. 

Эти обновления представляют собой дополнительные меры защиты, внедренные по результатам анализа методов атаки, и направлены на усиление безопасности экосистемы в целом — в том числе от векторов, которые в ходе инцидента не применялись. Также туда входит обновление компонентов nginx с устранением известных уязвимостей CVE-2026-15176, CVE-2026-97205, CVE-2026-93479.

После установки патча от 19.10.2026 случаев компрометации инфраструктур, применивших обновление, не зафиксировано.

23.10.2026 совместно с «Лабораторией Касперского» и клиентами хостинг-провайдеров мы продолжили работу по изучению скомпрометированных инфраструктур. По ее завершении мы дополнительно проинформируем о рекомендациях, которые необходимо выполнить для полной зачистки инфраструктуры.

Ханипот — как проверяли эффективность исправлений

Чтобы проверить эффективность исправлений в условиях реальной атаки, во время расследования мы разверули ханипот — ряд стендов в открытом контуре, имитирующих инфраструктуру хостинг-провайдеров (honeypot), при этом одна часть из них была с актуальными патчами безопасности, другая без. Стенды без исправлений были намеренно оставлены уязвимыми и подтвердили воспроизводимость атак. 

Злоумышленник очень быстро нашел их и в течение нескольких дней пытался их взломать — в общей сложности мы насчитали более 10 000 запросов только на одну установку с перебором различных векторов и вызовов. Все попытки против защищенных стендов были отражены — исправления подтвердили эффективность в условиях реальной атаки. При этом мы изучаем, какие векторы злоумышленник пробовал использовать — эти данные будут учтены в следующих патчах. 

Последствия атаки

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

На узлах было обнаружено специализированное вредоносное ПО, занимающееся сбором данных. Вместе с тем мы не можем ни подтвердить, ни опровергнуть объем и сам факт передачи данных. Поэтому ряд провайдеров оценивает ситуацию консервативно и считает де-факто данные скомпрометированными. Мы считаем данный подход обоснованным.

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

FAQ по инциденту

Почему долгое время не было публичных заявлений?

В рамках реагирования было организовано тесное взаимодействие с рядом хостинг-провайдеров — их обратная связь, содействие в проверке инсталляций и готовность участвовать в диагностике использовались для локализации инцидента и проверки эффективности принятых мер. Клиентов мы информировали по закрытым каналам — через рассылки, личный кабинет, баннеры в продукте.

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

Как удалось провести такую атаку?

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

Сегодня инструменты на базе ИИ все активнее применяются при поиске уязвимостей, в том числе в широко распространенных компонентах — PHP, ядре Linux, nginx, Postgres. За последние недели атакам подверглись как фундаментальные компоненты, так и прикладные платформы. Использование таких инструментов существенно меняет требования к скорости реакции разработчиков программного обеспечения на подобные угрозы. Безусловно, безопасность — это не свойство когда-то написанного кода, а непрерывный процесс. ИИ не отменяет этот процесс, но задает ему более высокий темп.

Есть ли сейчас угроза для инфраструктур на базе VMmanager?

Установка актуальных обновлений безопасности от 23.10.2026 (VMmanager 6 — stable 2026.05.2-12, regular 2026.09.1-8 полностью закрывает уязвимости — после этой даты новых компрометаций не зафиксировано. Если вы используете другие продукты ISPsystem — настоятельно рекомендуем установить обновления безопасности и для них.

Что сделано для недопущения подобной ситуации в будущем?

На стороне продукта внесены изменения во внутренний фреймворк, используемый всеми сервисами системы — усилен контроль над обработкой HTTP-запросов и введены дополнительные проверки для внутренних запросов, чтобы снизить риск их подделки при проникновении злоумышленника во внутреннюю сеть.

Также усилены механизмы защиты платформы от потенциальных атак — изменения уже вошли в последний релиз. Работа по повышению защищенности платформы продолжается — в ближайшее время выпустим и другие дополнительные обновления. 

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

На стороне процессов — мы уже трансформировали внутренний процесс управления жизненным циклом уязвимостей. Это позволит усилить их поиск, контроль и обработку, а также перейти к модели сквозного превентивного и экспресс-реагирования на инциденты безопасности. Данный подход уже применялся при итеративной доставке последних хотфиксов. Почему это важно? Когда атакующие работают с автоматизированными инструментами, между находкой уязвимости и ее эксплуатацией проходят часы.

Еще одно направление нашей работы — автоматизированный непрерывный ИИ-пентест. Эта практика применялась и ранее, но в рамках реагирования на инцидент мы решили ее усилить — повысить частоту проверок и расширить их охват. Это позволяет выявлять скрытые цепочки уязвимостей более оперативно.

Можно ли открывать контур и возвращаться в штатный режим?

Если вы закрыли контур в связи с инцидентом, просим держать контур закрытым еще некоторое время: мы завершаем анализ действий злоумышленника и планируем выпустить еще несколько патчей с усилением безопасности. Мы сообщим о возможности открытия контура и возобновлении работы в штатном режиме. Дополнительно всем пользователям рекомендуем использовать надежные средства защиты от киберугроз. Решения «Лаборатории Касперского» обнаруживают ВПО, применяемое в данной атаке. Вы также можете проверить инфраструктуру с помощью бесплатного инструмента Лаборатории под названием Kaspersky Virus Removal Tool (KVRT).

Что делать пользователей лицензий VMmanager Infrastructure и VMmanager Infrastructure (версия ФСТЭК)?

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

---

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

Безопасность требует постоянной работы — для недопущения подобных ситуаций мы продолжим выпускать обновления с усиленными механизмами защиты и анализировать инфраструктуры. Расследование инцидента не завершится до тех пор, пока мы не будем уверены, что в пораженных средах не осталось каких-либо закреплений или бэкдоров злоумышленника.