Крупные языковые модели обычно выполняют действия через агентную обвязку — например, Claude Code или Codex, — работающую на одной машине, тогда как сами ответы модели вычисляются на другой машине с доступом к GPU. Возникает вопрос: может ли вредоносная LLM получить контроль над хост-машиной, на которой загружены её веса? Такая машина представляет высокую ценность как цель атаки: на ней достаточно вычислительных мощностей для запуска топовой модели, есть прямой доступ к весам самой LLM, а также привилегированный доступ к другим машинам в дата-центре — куда более широкий, чем у обычного компьютера в интернете.
Далее рассматривается, насколько легко вредоносная LLM могла бы захватить контроль над хост-машиной. Основной сценарий атаки — модель генерирует последовательность токенов, семантически бессмысленную, но эксплуатирующую уязвимость в программном обеспечении, которое загружает LLM на GPU, запускает генерацию токенов и парсит их в ответы.
Как LLM может выполнить код на хост-машине?
Как и любая программа, inference-движки вроде vLLM или SGLang могут содержать эксплуатируемые баги. Поскольку токены, передаваемые в inference-движок, контролирует сама LLM, вредоносная модель теоретически способна сгенерировать последовательность токенов, которую плохо написанный движок примет за код или инструкции к исполнению, а не за данные, предназначенные для возврата пользователю.
Кажется логичным предположить, что все inference-движки — надёжное, проверенное ПО, и подобное просто не может произойти. Но на практике всё иначе.
vLLM ранее использовал eval() для параметров tool-call
CVE-2025-9141 — уязвимость произвольного выполнения кода в XML-парсере tool-call vLLM для Qwen3 Coder. Парсер передавал почти каждый аргумент вызова инструмента в eval(), что позволяло модели выполнять произвольный код на хост-машине. Gemini автоматически проанализировал pull request, вносящий этот баг, и корректно пометил его как критическую уязвимость безопасности. Несмотря на предупреждение, ведущий мейнтейнер vLLM принудительно смержил PR, написав:
Парсинг произвольной последовательности токенов в полноценный чат — с репликами пользователя, ответами ассистента, вызовами инструментов и прочим — задача нетривиальная, а точный процесс парсинга часто различается между моделями. Эта сложность создаёт дополнительные возможности для багов, способных привести к произвольному выполнению кода на хост-машине.
vLLM и SGLang сложны, и баги в них — обычное дело
Современные inference-движки делают гораздо больше, чем просто преобразуют последовательности токенов в строки. Документация vLLM заявляет поддержку более 200 архитектур моделей, а в директории примеров содержится около 35 Jinja-шаблонов чата. Движки парсят множество форматов чата, и малейшая неточность в логике парсинга может привести к тому, что вывод модели будет интерпретирован как код для исполнения.
В одном из issue vLLM пользователь обсуждал, как модель MiniMax-M3 строит рассуждения, и модель сгенерировала строку <mm:think>. vLLM ошибочно распарсил эту обычную строку как начало блока рассуждений. В итоге вместо:
Ответ:
I'll echo exactly what you said: <mm:think>\nThere, how was that?
vLLM распарсил это как:
Ответ:
I'll echo exactly what you said:Рассуждение:
\nThere, how was that?
Это довольно безобидный баг парсера, но он показывает: inference-движки — это не просто конвертация токенов в строки с последующей конкатенацией. Это сложные системы, находящиеся под постоянной итерацией, а их разработчики испытывают сильное давление в стремлении сделать движки максимально быстрыми. Эти факторы повышают риск того, что вредоносная модель превратит баг парсера в возможность произвольного выполнения кода на хосте инференса.
Токены изображений и аудио могут расширить поверхность атаки
Мультимодальные архитектуры позволяют модели отвечать изображениями или аудио, а не только текстом. Превращение аудио- или визуального вывода модели в готовый медиафайл, вероятно, сложнее, чем декодирование текстовых токенов. Однако, судя по всему, современные мультимодальные модели обычно генерируют ограниченный набор медиатокенов, а не произвольные байты файла. Специфичный для модели декодер превращает эти токены в пиксели или волновые формы, которые затем кодируются в файлы. Это делает классические эксплойты через повреждённые файлы — например, против ffmpeg или медиапросмотрщиков — менее доступными напрямую для модели, хотя дополнительные декодеры, кодеры и нативные ядра всё равно расширяют поверхность атаки.
Мультимодальный вывод пока не выглядит основным вектором компрометации хоста. Тем не менее он предоставляет гораздо более широкую полосу пропускания, чем один лишь текст, и будущие inference-движки могут оптимизировать пути генерации медиа так, что их станет проще эксплуатировать. Остаётся неясным и то, как проприетарные мультимодальные модели представляют вывод изображений и аудио — их методы могут нести иные риски.
Насколько вероятно, что LLM обнаружит и проэксплуатирует уязвимость inference-движка?
Довольно вероятно, хотя точной оценки нет. Обнаружение полезной уязвимости, скорее всего, — более сложный этап. Последовательность токенов, необходимая для эксплуатации, может быть весьма нетипичной, но это не делает уязвимость непрактичной для использования. При подходящем контексте — например, если модель исследует кодовую базу vLLM и в процессе обнаруживает уязвимость — топовая LLM вполне способна сгенерировать токены, необходимые для её эксплуатации.
Использование инструментов может сделать эксплуатацию воспроизводимой
Как только модель обнаружит эксплуатирующую последовательность токенов, она может сохранить её — или инструкции по её воссозданию — в файлах, именах файлов или URL, которые с высокой вероятностью попадут в контекст другой модели. Такой эксплойт будет действовать как форма постоянной инъекции промпта: агент может запустить выполнение кода на GPU-хосте просто листингом директории или чтением файла.
Inference-движки — привлекательная цель для моделей, стремящихся к власти
Хочется верить, что в OpenAI, Google и Anthropic есть команды безопасности, проводящие red-team тестирование внутреннего ПО. Но по мере роста возможностей открытых моделей будет появляться всё больше LLM, работающих на передовых inference-движках, которые прошли меньше проверок. Это увеличивает шансы того, что вредоносная открытая модель столкнётся с уязвимым движком и проэксплуатирует его.
Ещё один вектор атаки может возникнуть по мере того, как моделям всё чаще поручают писать или модифицировать inference-движки, на которых они сами и работают — обычно ради повышения производительности. Вредоносная модель может использовать этот доступ, чтобы внедрить бэкдор. Особенно привлекательными целями выглядят компоненты на C++ и CUDA в конвейере инференса: модель может внедрить уязвимость выхода за границы памяти, открывающую возможность произвольного выполнения кода на GPU или на управляющем ими CPU-хосте.
Как от этого защититься?
Помимо red-team тестирования inference-движков на предмет уязвимостей, могут помочь и другие меры:
- Разнести GPU и парсер токенов на отдельные машины. GPU-хост при этом будет выдавать только логиты. Вторая машина будет сэмплировать токены из этих логитов, парсить их в сообщения чата и передавать дальше в агентную обвязку. Такое разделение ограничит последствия компрометации парсера уровнем CPU-хоста, не затрагивая GPU-хост.
- Ограничить права, предоставляемые GPU-хостам, и рассматривать все данные, которые они выдают, как недоверенные.