Критическая уязвимость CVE-2026-105192 в LMCache, используемом для ускорения серверов больших языковых моделей вроде vLLM, позволяет неаутентифицированному удалённому злоумышленнику выполнять произвольный код на сервере кэша при включённом мультипроцессном режиме, патча пока нет; организации, использующие LMCache с сетевым доступом к ZeroMQ‑сокету, должны немедленно перевести его на локальный или доверенный сегмент и пересмотреть конфигурации Kubernetes‑развёртываний.
Технические детали уязвимости
Уязвимость CVE-2026-105192 затрагивает LMCache начиная с версии 0.3.9 и вплоть до стабильной 0.5.5, а также кандидаты релиза 0.5.6 и текущую ветку разработки. Описание CVE опубликовано в базе CVE (карточка CVE-2026-105192), формальная запись в NVD может быть доступна по шаблону NVD CVE-2026-105192, а технический разбор представлен в advisory JFrog (JFrog JFSA-2026-001694382).
Ключевые технические моменты:
- Уязвимость проявляется в multiprocess mode LMCache, где кэш работает как отдельный сервер, а рабочие процессы LLM подключаются к нему через библиотеку ZeroMQ. Режим описан в официальной документации LMCache: multiprocess mode.
- Сервер LMCache по умолчанию слушает только localhost. Риск появляется, когда оператор явно указывает маршрутизируемый адрес (например, при межузловом кластере), делая ZeroMQ‑сокет доступным из сети.
- В мультипроцессном режиме существует тип сообщения, который на стороне сервера десериализуется через Python‑механизм pickle до проверки типа сообщения. Соответствующий код виден в репозитории LMCache (ipc_wrapper.py).
- Так как:
- на ZeroMQ‑сокете отсутствует аутентификация;
- формат pickle допускает выполнение произвольного кода в процессе десериализации;
- проверка типа сообщения выполняется после распаковки данных, —
любой удалённый клиент, способный установить соединение с этим сокетом, может отправить специально сформированное сообщение и добиться выполнения своего кода с правами процесса LMCache.
- По данным JFrog, в официальных контейнерных образах LMCache процесс кэша выполняется с правами root, что масштабирует проблему десериализации в полный захват узла.
Особенность конфигурации усугубляет риск: в официальном примере Kubernetes‑развёртывания multiprocess‑сервера LMCache (lmcache-daemonset.yaml) сервер настроен на прослушивание всех сетевых интерфейсов, а не только localhost. Такой пример часто без изменений копируется в рабочие кластеры, что делает экспозицию вероятнее.
Разработчики LMCache пока не опубликовали официальный security advisory в разделе security advisories, и исправленный релиз отсутствует. Эксплуатация уязвимости «в дикой природе» в исходном материале не фиксируется, но вектор атаки тривиален, не требует аутентификации и не привязан к конкретной версии Python или ZeroMQ, что делает практическую эксплуатацию крайне реалистичной.
Контекст угроз: повторяющийся шаблон ShadowMQ
Исследователи JFrog указывают, что логическая ошибка совпадает с найденной ранее серией уязвимостей в инфраструктуре ИИ‑инференса, получивших условное название ShadowMQ: данные с неаутентифицированного сетевого сокета напрямую передаются на десериализацию через pickle. Это не единичная ошибка конкретного проекта, а устойчивый анти‑паттерн в дизайне высокопроизводительных IPC и сетевых компонентов в AI‑стеке.
Примечательно, что LMCache не единственный компонент цепочки. В экосистеме vLLM уже исправлена отдельная уязвимость отказа в обслуживании CVE-2026-105756, при которой единичный запрос с некорректным значением cache_salt мог аварийно завершать движок при использовании коннектора LMCache multiprocess. Подробности доступны в advisory проекта vLLM (GHSA-2823-qmq8-rwvj). Там речь идёт лишь о краше процесса, а не о выполнении кода, но в совокупности это подчёркивает: связка LLM‑движок + кэш + межпроцессная коммуникация стала новой плоскостью атак.
Дополнительные тикеты в GitHub‑репозитории LMCache (например, issue #5507 и issue #5508) описывают предположительные проблемы с неаутентифицированным доступом к данным кэша и командам различных сетевых сервисов, но они пока не подтверждены мейнтейнерами, не имеют CVE и исправлений. Для практической оценки рисков их стоит учитывать как индикатор общего состояния модели доверия в продукте, а не как формально верифицированные уязвимости.
Оценка воздействия на организации
Наивысший риск несут среды, где совпадают следующие факторы:
- использование LMCache в multiprocess mode с сетевой доступностью ZeroMQ‑сокета с других хостов (включая multi-node кластеры);
- микросервисная или Kubernetes‑архитектура, развёрнутая по примеру официального daemonset, с привязкой сервера к «всем интерфейсам»;
- выполнение контейнера LMCache с правами root или с доступом к разделяемым томам, содержащим токены доступа, конфигурации LLM‑движка, журналы запросов пользователей.
Потенциальные последствия при успешной эксплуатации:
- Полный компрометирующий доступ к узлу с LMCache: установка бэкдоров, криптомайнинга, использование узла как точки опоры для дальнейшего lateral movement.
- Компрометация конфиденциальных данных:
- доступ к содержимому кэша (фрагменты промптов, ответы моделей, промежуточные представления);
- доступ к файловой системе контейнера/узла с возможным раскрытием секретов оркестратора и LLM‑платформы.
- Срыв доступности AI‑сервисов: произвольные команды могут останавливать процессы, потреблять ресурсы, изменять конфигурацию или использовать кэш как канал для последующих атак.
Наибольшую угрозу получают:
- поставщики LLM‑сервисов и внутренние AI‑платформы с multi-tenant моделью;
- облака и крупные кластеры, где кэш разделяется между узлами и возможны пересечения сетевых доменов доверия;
- любые среды, где LMCache развёрнут без строгой сетевой сегментации (общие кластерные сети, доступ со вспомогательных сервисов, разработческих namespace и т.п.).
Практические рекомендации по защите
1. Немедленная приоритизация и изменение сетевой экспозиции
- Определите все развёртывания LMCache:
- по зависимостям LLM‑платформ (например, vLLM),
- по образам в реестре контейнеров, содержащим название
lmcache, - по конфигурациям Kubernetes, использующим пример daemonset из официального репозитория.
- Для всех экземпляров multiprocess‑сервера:
- ограничьте прослушиваемый адрес localhost или строго доверенным подсетям кластера;
- исключите возможность подключения с пользовательских сегментов, VPN‑зон общего назначения и интернета.
- Используйте сетевые политики Kubernetes, отдельные security‑группы или межсетевые экраны, чтобы минимизировать круг хостов, имеющих доступ к ZeroMQ‑сокету. При этом следует исходить из допущения: любой хост с сетевым доступом способен выполнить RCE.
2. Уменьшение привилегий и жёсткий runtime‑контроль
- Пересоберите или переопределите контейнеры LMCache так, чтобы процесс не работал от root:
- задать не-привилегированного пользователя в Dockerfile или в PodSpec;
- отключить лишние capability ядра и доступ к hostPath‑томам.
- Включите контроль поведения контейнеров (seccomp, AppArmor или аналогичные механизмы), чтобы ограничить системные вызовы и затруднить пост‑эксплуатацию.
3. Патчи и версии сопутствующих компонентов
- Обновите vLLM до версии 0.30.0 или новее, чтобы исключить уязвимость DoS CVE-2026-105756 в LMCache‑коннекторе (advisory vLLM).
- Следите за выходом исправленного релиза LMCache в разделе security advisories и в документации multiprocess mode; запланируйте ускоренное обновление, как только патч будет доступен.
4. Мониторинг и индикаторы возможной эксплуатации
JFrog не публикует явных индикаторов компрометации (IP‑адреса, хэши вредоносных образов и т.п.), но можно предпринять следующие шаги:
- Анализировать журналы сети и Kubernetes на предмет:
- подключений к порту LMCache multiprocess‑сервера из нетипичных подсетей или namespace;
- аномального роста числа регистраций воркеров или неожиданных перезапусков подов с LMCache.
- Проверить узлы, где работает LMCache, на:
- наличие неизвестных процессов и cron‑заданий;
- изменения в контейнерных образах, томах с конфигурацией и бинарях.
- Включить дополнительный аудит команд и системных вызовов контейнеров LMCache до выхода официального исправления.
Критический вывод: до появления патча к CVE-2026-105192 единственной реальной защитой остаётся жёсткое ограничение сетевого доступа к multiprocess‑серверу LMCache и отказ от запуска его с привилегиями root; первым шагом должна стать инвентаризация всех развёртываний LMCache и немедленное переподключение ZeroMQ‑сокета на локальные или строго контролируемые сегменты сети.
