Ответ модели может захватить сервер: парсер vLLM прогонял его через Python eval()

Починили примерно через месяц. Всё это время парсер tool-call для Qwen3-Coder прогонял аргументы из ответа модели через Python eval(), и любой пользователь с доступом к API выполнял код на сервере. Это CVE-2025-9141, CVSS 8.8.

Выход модели стал вводом. Бойд Кейн поднимает случай до правила: текст, который выдала модель, разбирает код на той же машине, где стоит GPU. Документация vLLM заявляет поддержку 200+ архитектур, в каталоге examples лежит около 35 Jinja-шаблонов чата, и каждый из них парсит выход модели.

Три флага решают. vLLM уязвим к CVE-2025-9141 только при совпадении трёх условий: включён tool calling (--enable-auto-tool-choice), выбран парсер --tool-call-parser qwen3_coder, тип параметра не задан явно. Под ударом версии от 0.10.0 до 0.10.1.1, обновление до 0.10.1.1 закрывает дыру.

У Ollama свой сюжет. Дыру CVE-2026-7482 закрыла версия v0.17.1 от 25 февраля 2026, но в релиз-нотах фикс не пометили как security, и сигнала срочности операторы не получили. Тем временем около 300 000 инстансов доступны из интернета без аутентификации: три вызова API вычитывают heap процесса вместе с чужими промптами, env-переменными хоста и ключами API. Уходит это через штатный эндпоинт /api/push на сервер атакующего.

Хардининг Ollama держится на настройках. Бинд на 127.0.0.1 вместо 0.0.0.0, auth-прокси или API-gateway перед каждым инстансом (во встроенном REST API аутентификации нет вообще), ротация всех секретов, если инстанс был доступен из интернета до патча. Чувствительные env-переменные в процесс Ollama лучше не передавать.

Запрос на /v1/rerank рендерит chat_template прямо из GGUF-файла модели через несэндбоксенный jinja2.Environment(), а это выполнение произвольного Python на сервере: CVE-2026-5760, CVSS 9.8. CERT/CC указал, что в ходе координации ответ от проекта получить не удалось. Предложенное исправление умещается в одну замену: ImmutableSandboxedEnvironment вместо jinja2.Environment().