Все три платформы выполняют разные задачи, но занимают особенно выгодное для атакующих место. LiteLLM работает как шлюз между приложениями и поставщиками больших языковых моделей, RAGFlow обрабатывает документы и организует генерацию с поиском по внешним данным, а Kestra запускает автоматизированные рабочие процессы. Подобные системы часто имеют доступ сразу к ключам API, базам данных, внутренним сервисам, конфигурации контейнеров и вычислительным ресурсам. Если скомпрометирован один компонент, это открывает гораздо больше возможностей, чем взлом обычного веб-приложения.
Самая насыщенная цепочка атаки обнаружена в LiteLLM. Microsoft с высокой уверенностью считает, что злоумышленники проникли через открытый в интернет шлюз. Возможный путь связан с уязвимостью CVE-2026-42271 (8,8), которая позволяла авторизованному пользователю выполнять команды через тестовые интерфейсы Model Context Protocol (MCP), и уязвимостью CVE-2026-48710 (6,5) в Starlette. В определённых конфигурациях сочетание проблем позволяло выполнять код без действующих учётных данных. CVE-2026-42271 (8,8) затрагивала LiteLLM с версии 1.74.2 до 1.83.7, где разработчики закрыли проблему.
Проникнув в систему, атакующие первым делом полезли за секретами. В контейнерах, где LiteLLM работает как процесс с идентификатором PID 1, вредоносный код читал файл
/proc/1/environ и искал значения со словами master, API key, token и password. Там могли находиться ключи поставщиков ИИ-моделей, главный ключ LiteLLM, адрес базы данных, пароли интерфейса и другие чувствительные параметры. Собранные данные отправлялись наружу несколькими способами через Python, curl и wget, чтобы сбой одного инструмента не остановил кражу. Следом злоумышленники загружали исполняемые ELF-файлы и маскировали процессы под обычные системные службы Linux. Вредоносные программы проверяли привилегии, открытые порты, запущенные майнеры и средства удалённого доступа. Затем атакующие устанавливали XMRig или похожие компоненты для добычи криптовалюты, настраивали процессор под алгоритм RandomX и удаляли конкурирующие майнеры, уже присутствовавшие на сервере.
Украденная строка подключения к PostgreSQL позволила перейти от захвата контейнера к данным самого LiteLLM. В одном из случаев база работала в Azure Database for PostgreSQL. Атакующие подключились к ней и выгрузили таблицы с настройками моделей и виртуальными ключами прокси. Такие записи могут содержать адреса поставщиков моделей, ключи API и параметры маршрутизации запросов. Чтобы закрепиться в системе, злоумышленники добавляли SSH-ключ в
authorized_keys, меняли задания cron, прятали файлы во временных каталогах и присваивали вредоносным файлам неизменяемый атрибут Linux. В RAGFlow сценарий выглядел иначе. Сначала Microsoft заметила действия, похожие на разведку методом Server-Side Request Forgery (SSRF), когда приложение само обращалось по адресу, заданному атакующим. Через несколько дней в том же контексте появилось выполнение кода. Microsoft не смогла установить конкретную уязвимость, поэтому не связывает инцидент напрямую ни с одной известной ошибкой RAGFlow.
В качестве возможного технического контекста специалисты перечислили несколько ранее раскрытых проблем. Среди них серверная инъекция шаблонов CVE-2026-45312 (9,9) в генераторе запросов, похожая уязвимость CVE-2026-28797 (8,7) в компонентах Agent, ошибка обхода каталогов CVE-2026-24770 (9,8) в MinerU Parser, а также CVE-2025-68700 (9,4) и CVE-2025-69286 (9,8). Наличие перечисленных уязвимостей само по себе не доказывает, что атакующие применили одну из них в обнаруженном случае.
Получив доступ к RAGFlow, злоумышленники создали скрытый Python-модуль внутри каталога приложения и изменили механизм запуска, чтобы вредоносный код загружался вместе с сервисом. Главной целью стали не вычислительные ресурсы, а новые учётные данные. Вредоносный модуль перехватывал настройки, когда пользователь добавлял или менял подключение к большой языковой модели. В руки атакующих попадали название поставщика, модель, ключ API и адрес сервиса. Microsoft наблюдала такой механизм для учётных данных OpenAI, Azure, Anthropic и Gemini.
Перехваченные сведения незаметно отправлялись на внешний сервер, причём вредоносный код подавлял ошибки передачи, чтобы работа RAGFlow внешне продолжалась как обычно. Майнеров или интерактивной обратной оболочки в данном инциденте Microsoft не обнаружила. В контейнер также записали SSH-ключ, однако смог бы он пережить перезапуск, зависело от настроек файловой системы, привилегий контейнера и конфигурации границы между контейнером и хостом.
В случае Kestra специалисты с высокой уверенностью связывают первоначальный доступ с критической CVE-2026-49869 (10,0). Ошибка в фильтре аутентификации позволяла удалённому пользователю без пароля создавать и запускать собственные рабочие процессы. Поскольку Kestra штатно умеет выполнять Shell-, Python- и другие сценарии, уязвимость фактически превращалась в удалённое выполнение команд. Проблема затрагивала версии до 1.3.20 включительно, разработчики исправили её в 1.0.45 и 1.3.21.
Получив управление через Kestra, атакующие добрались до сокета Docker и начали просматривать параметры других контейнеров. Переменные окружения нередко содержат ключи облачных сервисов, пароли баз данных, токены API и внутренние адреса. Затем злоумышленники загрузили XMRig, переименовали исполняемый файл, запустили майнинг Monero и настроили RandomX, чтобы увеличить производительность процессора. В другой части атаки удалённый сценарий собирал сведения о системе, кодировал результат и сохранял данные через собственное хранилище ключей и значений Kestra.
Microsoft также заметила необычно аккуратную структуру некоторых вредоносных программ. Код содержал организованные импорты, обработку исключений, резервные способы загрузки зависимостей, тайм-ауты и поясняющие комментарии. Подобные признаки могут появляться в программах, созданных или доработанных при помощи ИИ. Специалисты подчёркивают, что подобных особенностей недостаточно, чтобы доказать применение генеративной модели или установить автора вредоносного кода.
Три инцидента показывают общий сдвиг в интересах атакующих. Шлюзы и платформы для ИИ постепенно превращаются в новый управляющий слой корпоративной инфраструктуры. Один такой сервис способен одновременно хранить ключи к моделям, подключаться к базе данных, запускать сценарии и управлять контейнерами. Поэтому злоумышленникам уже необязательно атаковать непосредственно ИИ-модель. Гораздо выгоднее захватить компонент, через который проходят запросы, секреты и команды.
Microsoft советует не публиковать административные интерфейсы подобных систем напрямую в интернете, регулярно устанавливать обновления, отделять пользовательские ключи от главных ключей поставщиков моделей и хранить секреты в специализированных хранилищах, а не в переменных окружения. Компания также рекомендует ограничить права сервисных учётных записей и баз данных, закрыть ненужный исходящий трафик и внимательно отслеживать случаи, когда процесс ИИ-шлюза внезапно запускает bash, Python, curl или wget. Особого внимания требуют случаи, когда кто-то читает
/proc/1/environ, обращается к Docker socket, запускает программы из /tmp, меняет SSH-ключи и cron, а также неожиданные соединения с серверами майнинговых пулов. По оценке Microsoft, защищать ИИ-инфраструктуру теперь нужно на том же уровне, что и другие критические управляющие системы компании. Чем больше полномочий получают шлюзы, платформы поиска и системы автоматизации, тем привлекательнее становится единая точка, через которую атакующий способен одновременно украсть секреты, получить доступ к данным и превратить серверы компании в собственные вычислительные ресурсы.