Атака на 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 (версия ФСТЭК)?

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

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

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