Коротко: 17 августа 2026 года в MLflow раскрыта CVE-2026-64849 (CVSS 9,3, CWE-918). Уязвимость — неаутентифицированный SSRF в обработчике webhook-тестирования: сервер следует HTTP-редиректам, не перепроверяя целевой адрес, что позволяет добраться до службы метаданных облака (169.254.169.254) и вытащить IAM-токены AWS/Azure/GCP. Затронуты все версии MLflow до 3.15.0. Патч — обновление до MLflow 3.15.0. CISA требует исправления для федеральных агентств США до 2 сентября 2026.
Содержание
Что такое MLflow и почему это важно
MLflow — это open-source система управления жизненным циклом ML-моделей, созданная компанией Databricks и переданная в Linux Foundation MLflow Projects (LFProjects). Платформа широко применяется в корпоративных MLOps-пайплайнах: она хранит логи экспериментов (метрики, параметры, артефакты), управляет реестром моделей и обеспечивает воспроизводимость обучения. MLflow-серверы, как правило, развёртываются в облачных окружениях — AWS, Azure или GCP — и имеют прямой доступ к IAM-ролям и секретам через переменные окружения или сервисы метаданных инстанса.
Именно это делает уязвимость CVE-2026-64849 настолько опасной: скомпрометированный MLflow-сервер находится в привилегированном сетевом сегменте и держит в памяти или в рядом расположенных сервисах облачные учётные данные, которые открывают доступ к базам данных, хранилищам, очередям и другим критическим ресурсам организации.
Как работает уязвимость — технически
CVE-2026-64849 — это Server-Side Request Forgery (SSRF) через обход редиректа: класс CWE-918, балл CVSS 3.1 — 9,3 (Critical). Уязвимый эндпоинт — POST /api/2.0/mlflow/webhooks/{id}/test, который предназначен для тестирования доставки webhook-уведомлений в реестре моделей.
Принцип атаки описан в публикации watchTowr:
- Атакующий регистрирует webhook с URL-адресом, который при HTTP-запросе ответит редиректом (301/302) на внутренний адрес — например, на сервис метаданных облака
http://169.254.169.254/. - MLflow отправляет тестовый запрос на исходный URL и проверяет его в момент регистрации — проверка проходит, потому что оригинальный адрес выглядит допустимым.
- Сервер следует редиректу в файле
mlflow/webhooks/delivery.py: он повторно разрешает имя хоста, не закрепляя первоначально проверенный адрес (hostname pinning отсутствует). - Ответ внутреннего сервиса (метаданные инстанса, переменные окружения и т.п.) возвращается в теле HTTP-ответа, который читает атакующий.
Ключевой момент: уязвимость обходит более ранние патчи, потому что предыдущие фиксы закрывали проверку URL до редиректа, но не после. Таким образом, атака работает даже на системах, где уже применялись частичные меры защиты.
Атака не требует аутентификации: любой, у кого есть сетевой доступ к Tracking Server MLflow, может отправить один HTTP-запрос и получить облачные ключи. Особенно уязвимы публично доступные или слабо сегментированные MLflow-инстанции в облаке.
Что крадут злоумышленники
Конечная цель атаки через CVE-2026-64849 — облачные учётные данные, которые хранятся по адресам link-local метаданных инстанса:
| Облако | Адрес метаданных | Что доступно |
|---|---|---|
| Amazon Web Services | 169.254.169.254/latest/meta-data/iam/ | Временные IAM-роль-ключи: AccessKeyId, SecretAccessKey, Token |
| Microsoft Azure | 169.254.169.254/metadata/identity/ | OAuth-токены Managed Identity |
| Google Cloud Platform | 169.254.169.254/computeMetadata/v1/ | Токены сервисного аккаунта, переменные окружения |
Похищенные IAM-токены временны, но срок их действия обычно составляет несколько часов — достаточно, чтобы атакующий успел скачать объекты из S3/Blob Storage, получить доступ к базам данных через роль, создать новых пользователей или развернуть дополнительные ресурсы в облаке. Помимо токенов, через тот же механизм доступны переменные окружения процесса MLflow — там нередко хранятся API-ключи к базам данных, секреты приложений и учётные данные для внешних сервисов.
Схожий сценарий — когда аналитическая платформа становится точкой входа к данным организации — описан в недавней истории с Metabase CVE-2026-72898: SQL-инъекция без пароля открыла BI-данные. Атаки на инфраструктурные инструменты MLOps и BI — отдельный вектор, требующий изоляции на уровне сети.
Масштаб эксплуатации и реакция регуляторов
По данным компании watchTowr, публично раскрывшей уязвимость 17 августа 2026 года, первые попытки эксплуатации через honeypot-сеть watchTowr Intel's Attacker Eye были зафиксированы в течение нескольких часов после публикации CVE. Независимо от watchTowr компания VulnCheck также задокументировала активное сканирование в дикой природе.
19 августа 2026 года Агентство кибербезопасности и инфраструктурной безопасности США (CISA) внесло CVE-2026-64849 в каталог Known Exploited Vulnerabilities (KEV). Согласно Binding Operational Directive 22-01, федеральные агентства США обязаны устранить уязвимость до 2 сентября 2026 года.
Уязвимость затрагивает все версии MLflow до 3.15.0, включая инстанции в продуктовых, экспериментальных и так называемых «теневых» MLOps-средах, которые часто не попадают в реестр активов компании. Именно последние представляют наибольший риск: они развёрнуты разработчиками или исследователями для экспериментов, имеют широкие облачные права, но не охвачены корпоративным мониторингом.
Атаки на AI-платформы в 2026 году участились — ранее в схожем контексте обсуждались вредоносные модели в экосистеме HuggingFace Diffusers: злоумышленники используют инфраструктуру ML-инструментов как плацдарм для проникновения в облако.
Как защититься
Основное действие — обновление MLflow до версии 3.15.0 или новее, в которой исправлена логика обработки редиректов в webhooks/delivery.py: теперь разрешённый адрес закрепляется после первой проверки (hostname pinning), и повторная перерезолюция при редиректе не происходит.
- Найдите все MLflow-инстанции в организации, включая dev-, staging- и «теневые» среды. Проверьте версию:
mlflow --versionили запрос к API/api/2.0/mlflow/version. - Обновите через pip:
pip install --upgrade mlflow>=3.15.0и перезапустите Tracking Server. - Изолируйте MLflow-сервер на уровне сети: доступ к порту должен быть только у авторизованных клиентов через VPN или service mesh. Публичный доступ без аутентификации — прямой путь к эксплуатации.
- Ограничьте IAM-права роли, под которой работает MLflow, по принципу минимальных привилегий: платформе нужен доступ к хранилищу артефактов и базе данных, но не ко всем ресурсам аккаунта.
- Проверьте логи за период с 17 августа 2026 года: нетипичные обращения к
/api/2.0/mlflow/webhooks/*/testс редиректами на 169.254.169.254 — признак атаки.
CVE-2026-64849 в MLflow активно эксплуатируется с 17 августа 2026 года. Обновление до 3.15.0 — единственное надёжное исправление. Параллельно стоит проверить сетевую изоляцию MLflow и сузить IAM-права сервера, чтобы возможный компромис не открыл доступ ко всему облачному аккаунту.
