В платформе для управления жизненным циклом машинного обучения MLflow обнаружена уязвимость подделки серверных запросов, известная как SSRF (Server-Side Request Forgery). Она позволяет атакующему без аутентификации заставить сервер отправлять запросы на произвольные адреса, включая внутренние ресурсы, и получать ответы на них. Проблема зарегистрирована под идентификатором CVE-2026-64849 и затрагивает все версии MLflow до 3.15.0. По данным исследовательской компании watchTowr, попытки эксплуатации начались в публичных атаках в течение нескольких часов после раскрытия сведений об уязвимости.
Уязвимость CVE-2026-64849
MLflow широко применяется в разработке и эксплуатации моделей машинного обучения. Его центральный компонент Tracking Server хранит метаданные экспериментов, параметры запусков, версии моделей и связанные с ними артефакты. В типовой установке сервер может быть доступен по сети без аутентификации, и именно такие конфигурации становятся целью атакующих.
Причина уязвимости - в функции проверки вебхуков реестра моделей. Вебхук представляет собой автоматическое уведомление, которое сервер отправляет на внешний адрес при наступлении события, например при регистрации новой версии модели. Точка для тестирования вебхуков не требует проверки подлинности. Любой посетитель может отправить запрос к этой точке, заставить сервер обратиться к указанному адресу и получить в ответ статус и содержимое страницы.
Разработчики MLflow уже пытались ограничить исходящие запросы. В версии 3.10.0 добавили проверку адресов назначения, которая запрещает вебхукам обращаться к закрытым или зарезервированным IP-адресам. Однако эта проверка выполняется только для первоначального имени хоста, указанного в конфигурации вебхука. Логика доставки сообщений следует за HTTP-перенаправлениями без повторной валидации и без привязки к проверенному адресу. Именно эту особенность используют злоумышленники.
Атакующий размещает публичный HTTPS-сервер, который успешно проходит первичную проверку, а затем отвечает перенаправлением на внутренний ресурс. Типичная цель - адрес службы метаданных облачного экземпляра, через которую сервисы получают информацию о собственном окружении, включая временные токены и учетные данные системы управления доступом IAM. Другая возможная цель - локальный сервис на адресе обратной петли. MLflow переходит по перенаправлению и возвращает содержимое ответа атакующему. В результате уязвимость дает возможность читать данные из внутренней сети.
Последствия зависят от окружения. Если MLflow развернут в облаке и имеет доступ к метаданным, злоумышленник может извлечь временные токены, ключи, параметры конфигурации и другие секреты. В корпоративной сети через SSRF можно добраться до внутренних панелей управления, баз данных и систем, не доступных из интернета. Атакующий получает прокси для разведки и кражи учетных данных внутри организации. Особенно рискованно сочетание публичного доступа к серверу, отсутствия аутентификации и наличия внутренних сервисов.
В watchTowr сообщили, что ее глобальная сеть приманок зафиксировала попытки эксплуатации CVE-2026-64849 сразу после присвоения идентификатора. Злоумышленники нацелены на извлечение паролей и секретов из облачных серверов MLflow. По наблюдениям исследователей, сканирование и атаки, скорее всего, продолжатся, а их масштаб вырастет.
Для защиты необходимо обновить MLflow до версии 3.15.0, в которой уязвимость исправлена. Перед обновлением важно выявить все установки MLflow в организации, включая разработочные, экспериментальные и теневые развертывания, появившиеся без ведома ИТ-отдела. Такие серверы часто остаются без мониторинга и потому наиболее уязвимы.
Кроме установки обновления, следует ограничить публичный доступ к Tracking Server, включить обязательную аутентификацию и разместить MLflow за обратным прокси-сервером или шлюзом, проверяющим личность пользователя. Нужно пересмотреть конфигурации вебхуков на предмет неизвестных или подозрительных адресов, которые могли быть добавлены атакующим. В журналах приложений и прокси стоит искать запросы к тестовой точке вебхуков, цепочки перенаправлений, обращения к адресам метаданных и необычную исходящую активность. При наличии признаков несанкционированного доступа необходимо ротировать облачные учетные данные и секреты, потенциально доступные скомпрометированному серверу.
Организациям следует исходить из худшего сценария: любой открытый MLflow версии до 3.15.0 может находиться под угрозой или уже был просканирован. Рекомендуется провести расследование для проверки следов обращения к метаданным или скрытой передачи данных.
Уязвимости класса SSRF относятся к числу тех проблем веб-приложений, которые позволяют обойти сетевые границы и получить доступ к внутренним ресурсам через внешнюю точку входа. Случай с MLflow показывает, что частичная проверка адресов недостаточна, если логика обработки перенаправлений не учитывает все возможные сценарии. Командам безопасности нужно действовать быстро, чтобы закрыть эту уязвимость до того, как ею воспользуются атакующие.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2026-64849
- https://x.com/watchtowrcyber/status/2089685887420440637
- https://github.com/mlflow/mlflow/security/advisories/GHSA-7gwp-5pfp-969j
