Критическая уязвимость vLLM позволяет выполнять удаленный код в AI-инфраструктуре
Организации, развёртывающие инфраструктуру искусственного интеллекта, получили серьёзный повод для беспокойства: обнаружена критическая уязвимость vLLM. Ошибка в обработке памяти открывает возможность удалённого выполнения кода через специально сформированные API-запросы. Она затрагивает одну из самых популярных платформ для обслуживания больших языковых моделей, и команды безопасности здесь вряд ли смогут отложить реакцию на потом.
В чём суть уязвимости vLLM
Проблема затрагивает версии vLLM 0.10.2 и выше, то есть большинство актуальных развёртываний в промышленной среде. По природе это уязвимость повреждения памяти: она возникает из-за некорректной обработки операций десериализации тензоров через конечную точку Completions API.
Брешь обнаружили исследователи из AXION Security Research Team и передали подробности разработчикам vLLM. Уязвимость сидит в файле entrypoints/renderer.py, строка 148: там система обрабатывает переданные пользователем тензорные встраивания без достаточных проверок.
Тревожнее всего то, что для эксплуатации не нужны привилегии. В зависимости от конфигурации API уязвимостью могут воспользоваться как аутентифицированные, так и неаутентифицированные пользователи.
Технические детали: как возникает повреждение памяти
Эксплуатация начинается с обработки встраиваний промптов через Completions API. Платформа десериализует тензоры функцией torch.load() без достаточной валидации данных.
Ситуацию усугубило изменение в PyTorch 2.8.0: там по умолчанию отключили проверки целостности разреженных тензоров, и это непреднамеренно открыло новый вектор атаки.
Злоумышленник готовит специально сформированный тензор, обходящий внутренние проверки. При дальнейшей операции to_dense() происходит запись за пределы выделенной памяти, а значит, появляется возможность выполнить произвольный код внутри процесса сервера.
Удалённое выполнение кода: почему это критично
Переход от повреждения памяти к удалённому выполнению кода — самый опасный аспект этой уязвимости vLLM. Получив возможность записи за границы памяти, атакующий может менять критические области памяти, включая:
- структуру исполняемого кода
- указатели на функции
- управляющие блоки процесса
Правильно собранная вредоносная нагрузка даёт атакующему полный контроль над сервером vLLM. На практике это открывает путь к тому, чтобы:
- красть обучающие датасеты и проприетарные ML-модели
- перемещаться латерально по сети
- устанавливать бэкдоры и разворачивать дополнительное вредоносное ПО
- подменять выводы моделей для дезинформационных атак
- перехватывать данные, проходящие через AI-систему
Completions API делает эксплуатацию до обидного простой: достаточно иметь доступ к API и отправить вредоносное встраивание.
Кто в зоне риска
Риски распространяются на широкий спектр сценариев:
- производственные AI-развёртывания
- облачные среды и мультитенантные решения
- внутренние корпоративные LLM-сервисы
- исследовательские институты
- AI-провайдеров и SaaS-платформы
Хуже всего приходится общим инфраструктурам, где на одном сервере работают сразу несколько клиентов: успешная атака способна скомпрометировать всех арендаторов разом.
Что делать прямо сейчас
Разработчики vLLM уже выпустили патч, устраняющий уязвимость (pull request #27204).
Обновление до исправленной версии — задача номер один.
Процедуры экстренного исправления
Командам безопасности стоит:
- Запустить срочное обновление на всех инстансах vLLM.
- Протестировать обновление в staging-среде.
- Мониторить систему после установки патча.
AI-системы часто критичны, а их обновления не всегда безболезненны, но тяжесть уязвимости полностью оправдывает ускоренное внедрение патча.
Временные меры, если обновиться сразу не получается
Если обновить систему немедленно нельзя:
- ограничьте API-доступ только доверённым пользователям;
- сегментируйте сеть и используйте IP white-list;
- внедрите предварительную валидацию входных данных;
- временно отключите Completions API, если это допустимо для вашего кейса.
Как выстроить устойчивую безопасность AI-инфраструктуры
Инцидент подсвечивает фундаментальную проблему: безопасность ML-инфраструктуры требует иных подходов, чем классическая кибербезопасность.
Безопасная десериализация
Десериализация — один из главных источников уязвимостей в ML-стеке.
Здесь нужны:
- проверки размеров, типов и требований к памяти;
- проверка источника данных (подписей);
- запуск операций десериализации в песочнице.
Усиление безопасности API
API — первый рубеж обороны, и он должен держать удар.
Важные меры:
- rate limiting;
- анализ аномалий;
- строгая валидация всех параметров;
- детализированный логинг для расследований.
Многоуровневая защита ML-систем
- сегментация сети
- принцип минимальных привилегий
- RASP и мониторинг выполнения
- детектирование попыток эксплуатации в реальном времени
Почему ML-инфраструктура становится мишенью
Популярность LLM и ценность обученных на них моделей неизбежно привлекают:
- киберпреступников
- промышленных конкурентов
- государственные структуры
Между компетенциями дата-команд и команд безопасности по-прежнему есть разрыв: именно в нём чаще всего рождаются слепые зоны.
Нужна культура безопасности, выстроенная вокруг AI:
- обучение разработчиков ML безопасным практикам
- формализованные процессы security-review
- более глубокое понимание ML-рисков у киберспециалистов
Какие уроки стоит вынести
- Валидация входных данных обязательна, без исключений.
- Настройки по умолчанию критичны. Отключённые проверки в PyTorch — наглядный тому пример.
- Ответственное раскрытие уязвимостей работает и остаётся ключевым механизмом защиты сообщества.
- Регулярные специализированные аудиты безопасности ML-инфраструктуры — не роскошь, а необходимость.
Заключение
Уязвимость vLLM, позволяющая удалённо выполнить код, — веское напоминание: безопасность AI-инфраструктуры должна быть стратегическим приоритетом, а не пунктом в списке дел на потом. Немедленное устранение бреши — только первый шаг. Организациям предстоит выстроить архитектуру безопасности, адаптированную под специфику машинного обучения, а не унаследованную от классических веб-приложений.
Использовать мощь больших языковых моделей без разрушительных последствий от кибератак смогут только те компании, которые заранее выстраивают многоуровневую защиту, регулярно оценивают риски и системно тестируют AI-инфраструктуру, например через пентест инфраструктуры и приложений, работающих поверх ML-стека.