В открытом доступе появился эксплойт для уязвимости в LMCache, который запускает произвольные команды на узлах, доступных по служебному сетевому порту. Рабочий код 7 октября 2026 года выложила группа JFrog Security Research Team, одновременно с описанием самой ошибки. Уязвимость отслеживается как CVE-2026-105192, её оценка по шкале CVSS составляет 9.8. Исправленной версии на день публикации не существовало. Демонстрационный код выполняет команду от имени процесса LMCache, при этом выход за пределы контейнера на хост-систему он не показывает - это подчёркивают сами авторы.
Уязвимость CVE-2026-105192
LMCache ускоряет работу больших языковых моделей. Она хранит промежуточные результаты вычислений, так называемый кеш ключей и значений, и отдаёт их повторно, чтобы модель не пересчитывала одно и то же. Ошибка кроется в многопроцессном режиме, который называют также распределённым. В нём рабочие процессы регистрируются друг у друга и обмениваются блоками кеша через сокет ZeroMQ - библиотеку для быстрого обмена сообщениями между процессами. Сокет не защищён ни паролем, ни проверкой подлинности соединения. Разработчики исходили из того, что подключаться к нему будут только родственные процессы LMCache.
Сообщения на этом канале закодированы в формате MessagePack, компактном формате обмена данными. Одно из расширений формата помечено кодом 1 и передаётся в модуль, который восстанавливает объекты Python из байтового потока. Такая операция называется десериализацией. Внутри вызывается библиотека pickle, умеющая собирать из данных произвольные объекты вместе с инструкциями по их созданию. Злоумышленнику достаточно вложить в сообщение такой объект, и код сработает. Причём восстановление объектов происходит на этапе разбора аргументов запроса, то есть раньше, чем сообщение доходит до обработчика. Поэтому проверки аргументов и ошибки самого обработчика выполнение уже запущенного кода не отменяют.
Демонстрационный эксплойт отправляет одно составное сообщение через клиентский сокет ZeroMQ на порт 5555 - этот порт транспорт использует по умолчанию. Внутри сообщения спрятан объект, который при восстановлении выполняет системную команду. Результат попадает в файл во временном каталоге, что подтверждает работу под учётной записью процесса LMCache. После этого сервер записывает в журнал ошибку типа: обработчик получает возвращённое значение вместо ожидаемого объекта. Ошибка появляется слишком поздно и на ход атаки не влияет.
Масштаб проблемы зависит от конфигурации. По умолчанию транспорт слушает localhost, подключиться к нему можно только с той же машины. Оценка 9.8 относится к другому сценарию: администратор задаёт параметром --host маршрутизируемый адрес, чтобы узлы кластера обменивались кешем между собой. Если LMCache работает внутри процесса vLLM, среды для запуска языковых моделей, порт вообще не открывается. Официальные контейнерные образы запускают процесс LMCache от имени суперпользователя, поэтому внутри контейнера команды выполняются с максимальными правами. На хост-систему эксплойт при этом не выходит, и завышать его возможности не стоит.
Опасный участок кода появился в версии 0.3.9. Он остался в 0.5.5, последнем выпуске в реестре пакетов PyPI, в предварительных сборках вплоть до 0.5.6rc3 и в ветке разработки, которую специалисты проверяли 7 октября. Патча нет ни для одной из них. Уязвимость нашёл Юваль Моравчик из группы JFrog Security Research Team, описание опубликовано в уведомлении под номером JFSA-2026-001694382.
До выхода исправления администраторам разумно отказаться от параметра --host с адресом, доступным из сети, и оставить привязку к localhost. Если обмен между узлами всё же нужен, доступ к порту ограничивают правилами межсетевого экрана и размещают сервис в доверенном сегменте. Такие меры сужают круг тех, кто может подключиться, однако саму ошибку не устраняют: любая система, дотянувшаяся до порта, способна выполнить код с правами процесса LMCache. Разработчикам JFrog советует убрать pickle из сетевого пути и заменить его безопасным форматом, а сам транспорт закрыть аутентификацией. Подойдут, например, механизм CURVE в ZeroMQ или проверка подписи каждого сообщения. Привязку к маршрутизируемому адресу логично запрещать до тех пор, пока аутентификация не настроена.
История с LMCache вписывается в общую картину. Инфраструктура для работы с языковыми моделями растёт быстрее, чем её защита. Кеши, брокеры сообщений и служебные порты разворачивают в кластерах, где много хостов и мало проверок подлинности. Одна ошибка в разборе данных превращается в запуск чужого кода, а отсутствие готового патча оставляет администраторам только сетевые ограничения. Любой, кто окажется в той же сети, получает те же права, что и сам сервис.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2026-105192
- https://research.jfrog.com/vulnerabilities/lmcache-is-vulnerable-to-unauthenticated-remote-code-execution-via-pickle-deserialization-on-the-multiprocess-zmq-transport-cve-2026-105192-jfsa-2026-001694382/
