Уязвимость SSRF в LMDeploy эксплуатируется через 13 часов после раскрытия

Представьте консьержа в отеле, который доставит любую посылку по любому адресу, написанному на салфетке, — без вопросов, без проверки индекса. Примерно так функция load_image() в LMDeploy работает внутри производственных AI-стеков. И через тринадцать часов после того, как дверь была публично названа, кто-то вошёл и начал рыться в подсобке.

Тринадцать часов. Именно столько прошло между публичным раскрытием CVE-2026-33626 и первыми зафиксированными попытками эксплуатации. Метафора с консьержем будет возвращаться снова и снова, потому что суть этой истории — о том, кому вы доверяете что-то доставлять от вашего имени и к чему это доставленное имеет доступ на обратном пути.

Цифры

Уязвимость находится в LMDeploy — open-source инструментарии для управления большими языковыми моделями. Как сообщает SC Media, это уязвимость типа server-side request forgery в модуле vision-language. Уязвимый код — функция load_image(), которая обрабатывает URL-адреса, не проверяя, указывают ли они на внутренние или приватные IP-адреса. Если вы когда-либо отлаживали SSRF в обработчике вебхуков, вы уже понимаете суть проблемы, не читая дальше.

Цифра в тринадцать часов должна заставить технических руководителей насторожиться. Исследователи Sysdig зафиксировали попытки эксплуатации именно в этом окне после публичного раскрытия. Для сравнения: исторически базовый отраслевой срок для оппортунистического сканирования новых CVE измерялся днями, а для нишевого ПО — неделями. Тринадцать часов говорит о том, что злоумышленники либо следили за потоком раскрытий в реальном времени, либо уже запускали фаззеры против AI-инфраструктуры, о которой им было известно заранее.

То, что атакующие делали дальше, — довольно стандартный арсенал SSRF: сканирование портов внутренних сетей, обращения к AWS Instance Metadata Service для получения облачных учётных данных, зондирование экземпляров Redis и внеполосная DNS-эксфильтрация для извлечения данных через разрешение имён, когда прямые соединения заблокированы. Ничего принципиально нового. Новизна — в точке входа: эндпоинт vision-language модели.

Один нюанс заслуживает отдельного внимания: эксплуатация предполагала множество запросов, распределённых по разным vision-language моделям для обхода обнаружения. Это говорит о том, что злоумышленники достаточно хорошо понимали топологию развёртывания пользователей LMDeploy, чтобы перемещаться между моделями внутри одного инструментария. Это указывает либо на предварительную разведку, либо на уже распространённый плейбук в соответствующих уголках интернета.

Что действительно нового

SSRF старше большинства инженеров, читающих это. Техника фигурирует в материалах OWASP уже более десяти лет, и любой бэкенд-разработчик, реализовавший функцию «получи этот URL и покажи превью», в какой-то момент смотрел на фильтр приватных IP и задавался вопросом, правильно ли указаны диапазоны CIDR. Так что же здесь принципиально иное?

Новизна — в самой поверхности атаки. AI-инструментарии для инференса, подобные LMDeploy, начинали как исследовательский код: загрузить модель, запустить токены, выпустить что-то работающее. Модули vision-language в частности принимают URL на вход, потому что именно так передаётся изображение модели без base64-кодирования всей нагрузки в JSON-запросе. Удобство и есть уязвимость. Инструментарий делает именно то, что заявлено.

Второе новшество — оперативный темп. Кто угодно, наблюдавший за выходом CVE в пятницу вечером, знает мучительный разрыв между публичным раскрытием и патчем в продакшне. Тринадцать часов — настолько мало, что традиционный цикл управления патчами (проверка, стейджинг, планирование, деплой) не успевает провести даже первое совещание до начала эксплуатации. Для команд, запускающих LMDeploy за внутренним API-шлюзом с доступным из inference-пода облачным метадата-сервисом, это означает потерянные выходные.

Третье, и пожалуй, самое важное — профиль целей. AWS IMDS и Redis выбраны не случайно. Именно они хранят учётные данные и состояние сессий. Злоумышленник, способный перейти от эндпоинта обслуживания модели к IMDS, фактически превращает ваш кластер инференса в автомат по выдаче учётных данных. Hugging Face в своих руководствах по развёртыванию годами подталкивал инженеров к контейнеризированному инференсу, но контейнеры разделяют метадата-сервисы со всем остальным в VPC, если только вы специально не ограничиваете IMDSv2.

Консьерж больше не просто доставляет посылки. Ему сообщили, что шкафчик с мастер-ключами стоит прямо за его стойкой.

Что уже учтено в AI-разработке

Большинство опытных инженеров, читающих это, уже предполагали, что AI-инструментарий, особенно open-source слой, имеет проблему с накопленным техническим долгом по безопасности. Это уже учтено. Экосистема хостинга моделей росла быстро, ставя во главу угла удобство для исследователей и унаследовав уровень безопасности академических кодовых баз. Никто не удивлён, что SSRF обнаружилась в URL-фетчере vision-language. Скорее удивительно, что именно эта CVE не появилась шестью месяцами раньше.

Что не учтено: скорость вооружения против AI-специфичной инфраструктуры. Тринадцатичасовое окно говорит о том, что злоумышленники теперь рассматривают AI-инструментарии как первоочередные цели, а не второстепенные. Это сдвиг. Год назад предполагалось, что оппортунистические сканеры рано или поздно доберутся до CVE в AI-стеках. «Рано или поздно» теперь означает «до обеда на следующий день».

Также не учтено: защитный инструментарий вокруг AI-инференса всё ещё незрел. Стандартные правила WAF не знают, как выглядит легитимный vision-language запрос. Сетевые политики в большинстве развёртываний Kubernetes по умолчанию разрешают трафик от пода к IMDS. Агентные паттерны, описанные в документации Anthropic и аналогичных источниках, предполагают, что вопрос сетевого исходящего трафика уже решён, но на уровне обслуживания моделей этот вопрос зачастую остаётся открытым.

Альтернативная точка зрения

Вот непопулярное мнение: цифра в тринадцать часов, при всей её тревожности, может также означать, что экосистема обнаружения наконец заработала. Sysdig поймал попытки эксплуатации. Пять лет назад та же уязвимость могла бы молча эксплуатироваться месяцами, прежде чем кто-то заметил, — потому что никто не наблюдал за трафиком AI-инференса теми же инструментами, что направлены на традиционные веб-стеки.

Второй контраргумент: SSRF в load_image() — решаемая проблема с известной формой. Валидировать IP, блокировать приватные диапазоны, принудительно включить IMDSv2 с hop-limit один, ограничить исходящий трафик на сетевом уровне. Ничего из этого не требует изобретения новых защитных подходов. Реальный риск — не эта CVE. Это следующая, в следующем AI-инструментарии, в коде, который никто не аудировал, потому что инструментарию шесть месяцев и он выпускает новую фичу каждый вторник.

Если вы воспринимаете CVE-2026-33626 как единичный случай — вы его закроете и пойдёте дальше. Если вы воспринимаете его как репрезентативный образец того, как выглядит безопасность AI-инфраструктуры в 2026 году, вы начнёте задавать более жёсткие вопросы о каждом URL-фетчере, каждом хуке для вызова инструментов и каждой модели, которая принимает строку и превращает её в сетевой запрос.

Ключевые выводы

• Немедленно обновите LMDeploy, если используете модуль vision-language. Тринадцатичасовое окно эксплуатации означает, что для непропатченных развёртываний следует исходить из предположения о компрометации.
• Заблокируйте AWS IMDS на v2 с hop-limit один для всех inference-подов, а не только для тех, которые вы считаете уязвимыми. Облачные метаданные — это именно тот приз, который нужен злоумышленникам.
• Рассматривайте URL-фетчеры AI-инструментариев как ненадёжные точки исходящего трафика. Сетевые политики должны блокировать трафик от пода к приватным диапазонам, если это явно не требуется.
• Настройте обнаружение паттернов эксплуатации нескольких моделей. Злоумышленники в данном случае распределяли запросы по разным vision-language моделям, чтобы обойти мониторинг одного эндпоинта.
• Модель доверия консьержу — когда AI-инструментарий получает всё, что ему поручают получить, — является архитектурным изъяном. Пока валидация не встроена в инструментарий по умолчанию, следует считать, что каждый новый компонент AI-инфраструктуры поставляется с аналогичной уязвимостью.