Уязвимость SSRF в MLflow активно эксплуатируется: злоумышленники крадут облачные учётные данные

Коротко о главном

17 августа 2026 года злоумышленники начали массовую эксплуатацию CVE-2026-64849 — критической SSRF-уязвимости в MLflow с оценкой CVSS 9.3. Без какой-либо аутентификации атакующий отправляет запрос к тестовому webhook-эндпоинту и вынуждает сервер MLflow обратиться к облачным metadata-сервисам — так похищаются ключи доступа AWS, GCP и Azure. Уязвимы все версии платформы ниже 3.15.0. Сканирование открытых экземпляров MLflow началось в течение нескольких часов после присвоения CVE-идентификатора.

Если ваша команда использует разработку AI/ML-систем или эксплуатирует собственный инстанс MLflow для управления экспериментами и моделями, приоритет номер один — немедленное обновление до версии 3.15.0 и аудит облачных журналов на предмет компрометации.

Техническая суть уязвимости

CVE-2026-64849 — это уязвимость типа Server-Side Request Forgery (SSRF) в механизме тестирования webhook-интеграций MLflow. Корень проблемы — в эндпоинте POST /api/2.0/mlflow/webhooks/{id}/test, который доступен без авторизации и перед отправкой тестового запроса выполняет HTTP-перенаправление.

Логика ошибки следующая: злоумышленник создаёт webhook с вредоносным URL, вызывает тестовый эндпоинт и эксплуатирует то, как MLflow обрабатывает HTTP-редиректы — платформа послушно следует по цепочке и доходит до конечного адреса, который атакующий выбрал заранее. Именно через такое перенаправление достигаются внутренние ресурсы облачной инфраструктуры, в первую очередь endpoints метаданных виртуальных машин.

Примечательно, что уязвимость обходит ранее выпущенные исправления, направленные против SSRF-атак в MLflow. Это третий случай, когда защита webhook-слоя оказалась обойдена, что указывает на системную проблему в подходе к валидации внешних URL в платформе.

Что именно похищают злоумышленники

Главная цель атаки — облачные metadata-сервисы, предоставляющие временные учётные данные виртуальным машинам и контейнерам:

AWS. Эндпоинт Instance Metadata Service (IMDS) по адресу 169.254.169.254 отдаёт временные ключи IAM-роли, привязанной к экземпляру EC2 или контейнеру ECS/EKS. Если MLflow запущен с широкими разрешениями — например, правами на чтение S3-бакетов с артефактами моделей или секретами в AWS Secrets Manager — злоумышленник получает эти права немедленно.

GCP. Metadata Server по адресу metadata.google.internal возвращает OAuth-токен сервисного аккаунта, от имени которого работает инстанс. В типичных ML-пайплайнах такой аккаунт имеет доступ к Cloud Storage, Vertex AI, BigQuery и другим сервисам.

Azure. Azure IMDS (169.254.169.254/metadata) предоставляет токены управляемого удостоверения. Те MLflow-инсталляции, которые работают в AKS или на Azure VM с назначенной Managed Identity, уязвимы в полном объёме.

Помимо токенов виртуальных машин, через SSRF доступны внутренние HTTP-сервисы в той же сети: другие компоненты ML-платформы, Kubernetes API-сервер, внутренние реестры и хранилища секретов.

Скорость атак и масштаб угрозы

По данным исследователей Miggo Security, массовое сканирование на предмет доступных MLflow-инстансов началось в течение нескольких часов после того, как CVE-2026-64849 получил публичный идентификатор 17 августа 2026 года. Злоумышленники не ждали публикации детального технического разбора — достаточно было самого факта присвоения CVE.

MLflow — один из самых распространённых open-source инструментов жизненного цикла моделей. Его используют команды, которые занимаются разработкой и внедрением ML-моделей, для трекинга экспериментов, версионирования артефактов и управления деплоем. Многие организации запускают MLflow на облачных VM или в Kubernetes-кластерах с открытым веб-интерфейсом для удобства доступа команды — именно такие инсталляции стали мишенью.

Особая опасность в том, что MLflow традиционно работает в доверенной внутренней среде и нередко имеет расширенные права для доступа к обучающим данным, облачным хранилищам и реестрам моделей. Компрометация учётных данных MLflow-инстанса на практике означает компрометацию всей ML-инфраструктуры организации.

Что делать прямо сейчас

Последовательность действий для команд, эксплуатирующих MLflow:

1. Обновите MLflow до версии 3.15.0. Это единственное полное исправление. Установка патча — приоритет номер один; все остальные шаги снижают ущерб, но не закрывают вектор атаки.

2. Проверьте журналы на предмет признаков эксплуатации. Ищите POST-запросы к /api/2.0/mlflow/webhooks/ с путём /test, особенно если источник — внешний IP или нестандартный внутренний адрес. Подозрительны также запросы к 169.254.169.254 или metadata.google.internal в логах исходящих соединений сервера MLflow.

3. Ротируйте потенциально скомпрометированные ключи. Если MLflow работал с IAM-ролью AWS, сервисным аккаунтом GCP или Managed Identity Azure — перевыпустите учётные данные вне зависимости от того, нашли ли вы следы атаки. Злоумышленники могли действовать до того, как вы включили подробное логирование.

4. Ограничьте сетевой доступ к MLflow. Веб-интерфейс и API не должны быть доступны напрямую из интернета. Если внешний доступ необходим, используйте VPN или Zero Trust-прокси. Внутри кластера ограничьте исходящие соединения MLflow через сетевые политики: платформа не должна иметь возможность обращаться к произвольным внешним адресам.

5. Включите IMDSv2 на AWS. Обязательное использование IMDSv2 (Instance Metadata Service v2) с требованием токена для всех запросов существенно усложняет SSRF-атаки на AWS IMDS. Для облачных инфраструктур GCP и Azure аналогичные меры защиты metadata-эндпоинтов также доступны и должны быть включены.

6. Минимизируйте права IAM/IAC. MLflow не нужны права администратора или широкий доступ к S3/Cloud Storage. Применяйте принцип минимальных привилегий: роль должна включать только те разрешения, которые реально требуются для текущего этапа пайплайна.

Почему ML-инфраструктура привлекает атакующих

MLflow и аналогичные платформы MLOps находятся на пересечении нескольких факторов риска. Во-первых, они работают с ценными данными: обучающими датасетами, весами моделей, пайплайнами трансформации — которые представляют прямую коммерческую ценность. Во-вторых, для работы им нужны широкие облачные права, которые исторически выдавались щедрее, чем права production-сервисов. В-третьих, ML-инфраструктура нередко живёт в «серой зоне» корпоративной безопасности: за неё отвечают дата-сайентисты, а не DevSecOps-команда.

CVE-2026-64849 — не первая и не последняя SSRF-уязвимость в MLflow. Это третий случай обхода SSRF-защиты за 2026 год, что свидетельствует о структурной проблеме в том, как платформа обрабатывает внешние URL. Командам, самостоятельно размещающим MLflow, стоит заложить регулярный аудит безопасности ML-инфраструктуры в процессы DevSecOps наравне с аудитом production-сервисов.

Часто задаваемые вопросы

Затронуты ли только самостоятельно размещённые инстансы MLflow? В первую очередь — да. Организации, использующие MLflow через управляемые сервисы (например, встроенную интеграцию в Databricks), должны уточнить у своего провайдера статус патча. Открытые self-hosted инстансы подвержены наибольшему риску.

Нужна ли эксплойту аутентификация? Нет. CVE-2026-64849 эксплуатируется без аутентификации — атакующему достаточно сетевого доступа к MLflow API. Именно поэтому важно не только установить патч, но и ограничить сетевой доступ к платформе.

Что считать подтверждением компрометации? Наиболее надёжный индикатор — исходящие HTTP-запросы с сервера MLflow к адресам 169.254.169.254, metadata.google.internal, 169.254.169.254/metadata (Azure IMDS). Также проверьте активность IAM-роли или сервисного аккаунта в CloudTrail, GCP Audit Logs или Azure Monitor на предмет действий в нетипичное время или из нестандартных регионов.

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

Что делать, если обновление прямо сейчас невозможно? Временные меры: заблокируйте внешний сетевой доступ к MLflow API, запретите исходящие соединения к metadata-адресам через правила сетевого экранирования, включите IMDSv2 и создайте alert на POST-запросы к /webhooks/. Эти меры снижают риск, но не устраняют уязвимость.

Источники

The Hacker News — «Attackers Exploit MLflow SSRF Flaw to Steal Cloud Credentials and Secrets», 18 августа 2026 года.

Decipher (Duo Security) — «MLflow Bug Actively Exploited to Steal Credentials», 18 августа 2026 года.

Miggo Security / CVE-2026-64849 — техническое описание уязвимости и вектора атаки.