В LMCache нашли незакрытую RCE: CVE-2026-105192 открывает инференс-кластеры vLLM для захвата

7 октября 2026 года JFrog раскрыла критическую уязвимость CVE-2026-105192 (CVSS 9.8) в LMCache — слое KV-кэша, который ускоряет инференс-серверы vLLM. Одно неаутентифицированное сообщение ZeroMQ на порт кэш-сервера выполняет произвольный код. Исправленной версии нет, поэтому защита сейчас одна — не выпускать этот порт за пределы машины или доверенной сети.

Уязвимы все версии LMCache начиная с 0.3.9 (октябрь 2025 года) и до 0.5.5 — последнего стабильного релиза, а также кандидаты 0.5.6 и ветка разработки. Рабочий пример эксплуатации JFrog опубликовала вместе с отчётом, на GitHub уже появились сторонние PoC. Под ударом прежде всего команды, которые сами разворачивают LLM-сервисы и ML-инфраструктуру на своих GPU, а не ходят в облачные API.

Ниже — как устроена атака, в каких конфигурациях кэш действительно доступен снаружи, как проверить кластер за десять минут и что делать, пока мейнтейнеры готовят патч. Если внешнюю поверхность ваших сервисов давно никто не проверял, начните с разбора пентеста и того, что он показывает.

Что раскрыла JFrog 7 октября

Уязвимость нашёл исследователь JFrog Security Research Юваль Моравчик, в базе JFrog она числится как JFSA-2026-001694382. Ключевые факты:

• оценка CVSS — 9.8, класс слабости — небезопасная десериализация недоверенных данных (CWE-502);
• затронут многопроцессный режим LMCache, в котором кэш работает отдельным сервером, а воркеры vLLM обращаются к нему через ZeroMQ;
• порт транспорта по умолчанию — 5555, аутентификации на нём нет;
• на момент публикации исправления не существует ни в стабильной ветке, ни в релиз-кандидатах.

Почему одного сообщения хватает для захвата сервера

Сообщения в транспорте LMCache упакованы в формат msgpack. Для одного из типов — расширения с кодом 1, зарегистрированного под обёртку DeviceIPCWrapper, — данные распаковываются через pickle.loads. Pickle в Python умеет не только хранить объекты, но и вызывать функции при восстановлении, поэтому подсунутый атакующим объект исполняет его код.

Хуже всего момент срабатывания: распаковка происходит ещё при разборе аргументов запроса, до того как сервер проверит тип сообщения и передаст его обработчику. Атакующему не нужно знать протокол кэша или проходить какие-то этапы — достаточно отправить один кадр ZeroMQ на открытый порт. Код выполняется с правами процесса LMCache. Ряд профильных изданий отмечает, что в официальных контейнерах процесс запущен от root, — проверьте это в своих образах: от этого зависит, получит ли атакующий контейнер или весь узел.

Когда кэш-сервер действительно доступен извне

Важная оговорка, которую теряют в пересказах: по умолчанию многопроцессный сервер слушает только локальный адрес, и с другой машины до него не достучаться. Уязвимость становится удалённой, когда оператор запускает сервер с маршрутизируемым адресом через параметр --host. А именно так и делают в многоузловых установках, где один кэш делят несколько GPU-серверов, — ради этого LMCache часто и внедряют.

Отдельный риск — Kubernetes. Сервис, открытый внутри кластера без сетевых политик, доступен любому поду. Если в том же кластере живёт веб-приложение с собственной уязвимостью, взлом фронтенда превращается в захват GPU-узла с весами моделей, промптами пользователей и токенами доступа к хранилищам.

Как проверить свой инференс-кластер

1. Найдите LMCache во всех окружениях: pip show lmcache в образах и виртуальных окружениях, поиск по requirements, pyproject.toml и Helm-чартам. Любая версия от 0.3.9 и выше сейчас уязвима.

2. Посмотрите, на каком адресе слушает сервер: ss -ltnp | grep 5555 на узлах и аргумент --host в манифестах. Адрес 127.0.0.1 — локальный риск, 0.0.0.0 или IP узла — удалённый.

3. Проверьте, кто может достучаться до порта: правила файрвола и группы безопасности облака, сетевые политики Kubernetes, балансировщики. Порт 5555 не должен быть виден из интернета и из соседних неймспейсов.

4. Убедитесь, от какого пользователя запущен процесс, и при возможности уберите root через securityContext (runAsNonRoot, запрет повышения привилегий).

Что делать до выхода исправления

JFrog даёт короткий список: не назначать многопроцессному серверу маршрутизируемый адрес, держать порт на локальной машине или в доверенной сети кластера и закрыть его файрволом. На практике это означает сетевую политику Kubernetes, которая разрешает входящий трафик на 5555 только от подов vLLM, и запрет этого порта на периметре. Если без многоузлового кэша можно обойтись неделю-другую, проще временно вернуться к локальному режиму.

Параллельно стоит включить наблюдение: логировать подключения к порту 5555 с неожиданных адресов и следить за дочерними процессами LMCache — оболочка или curl, запущенные кэш-сервером, почти наверняка означают эксплуатацию. Когда мейнтейнеры выпустят патч, обновитесь и пересоберите образы, а не только поправьте зависимость в коде.

Часто задаваемые вопросы

Какие версии LMCache уязвимы к CVE-2026-105192? Все версии от 0.3.9 до 0.5.5 включительно, а также релиз-кандидаты 0.5.6 и ветка разработки. На 9 октября 2026 года исправленной версии нет.

Уязвим ли сам vLLM? Нет, уязвимость в LMCache — отдельном пакете кэша, который подключают к vLLM. Если LMCache у вас не установлен или работает в однопроцессном режиме, этот сценарий вас не касается.

Опасно ли, если сервер слушает только localhost? Удалённой атаки в этом случае нет, но любой процесс на той же машине или в том же поде может отправить вредоносное сообщение. Это локальное повышение возможностей, поэтому обновление всё равно понадобится.

Есть ли публичный эксплойт? Да. JFrog показала эксплуатацию одним сообщением на порт 5555 в своём отчёте, на GitHub выложены сторонние PoC.

Источники

JFrog Security Research — LMCache is vulnerable to Unauthenticated Remote Code Execution via Pickle Deserialization on the Multiprocess ZMQ Transport (CVE-2026-105192), 7 октября 2026 года (первоисточник).

The Hacker News — Unpatched Critical LMCache Flaw Lets Unauthenticated Attackers Run Code Remotely, октябрь 2026 года.

OpenCVE — CVE-2026-105192.