LMCache, программное обеспечение с открытым исходным кодом для ускорения серверов больших языковых моделей, включая vLLM, содержит критическую уязвимость CVE-2026-105192. Неаутентифицированный удалённый атакующий может добиться выполнения произвольных команд на сервере кэширования без учётной записи и пароля. О проблеме 7 октября сообщила компания JFrog; уязвимость обнаружил Yuval Moravchick из её команды по исследованию безопасности. Исправленной версии LMCache пока нет, а оценка опасности составляет 9,8 из 10.
Проблема возникает в многопроцессном режиме LMCache. В такой конфигурации программа запускается как отдельный сервер кэширования, а рабочие процессы LLM обмениваются с ним данными через библиотеку сообщений ZeroMQ. Специально сформированное сетевое сообщение заставляет сервер выполнить команды, выбранные атакующим. Код запускается с правами пользователя, от имени которого работает процесс LMCache.
Уязвимы версии LMCache от 0.3.9, выпущенной в октябре 2025 года, до 0.5.5, которая считается последним стабильным релизом. Под угрозой остаются также кандидаты на выпуск 0.5.6 и ветка разработки. Патча нет ни для одной из этих версий, поэтому обновление внутри текущего ряда само по себе не устраняет риск.
По умолчанию многопроцессный сервер принимает соединения только на localhost. В таком случае доступ к порту есть лишь у программ на той же машине. Опасная ситуация возникает после настройки прослушивания на маршрутизируемом адресе. Это бывает в многузловых развёртываниях, где несколько машин используют один экземпляр LMCache. Чем шире доступ к сетевому порту, тем больше потенциальных источников атаки.
Особого внимания требует официальный пример развёртывания LMCache в Kubernetes: сервер в нём запускается с прослушиванием на всех сетевых интерфейсах. При такой настройке к нему могут обращаться другие машины и сетевые клиенты. Напротив, экземпляр LMCache, работающий внутри одного процесса vLLM, не открывает уязвимый порт. Описанная проблема относится именно к автономному многопроцессному серверу.
Причина связана с обработкой сообщений ZeroMQ. Сокет, через который рабочие процессы регистрируются на сервере и передают кэшированные данные, не использует аутентификацию. Один из типов сообщений распаковывается средствами Python pickle. Этот формат способен содержать исполняемый код: он запускается уже во время декодирования объекта. LMCache разбирает сообщение при чтении его аргументов, ещё до проверки типа сообщения. Поэтому вредоносная нагрузка может сработать немедленно, до того как сервер поймёт, какую именно команду получил.
Последствия зависят от прав процесса LMCache. Если программа работает с привилегиями обычного пользователя, атакующий получает соответствующий уровень доступа. По данным JFrog, официальные контейнерные образы LMCache запускают процесс от имени root. В таком контейнере успешная эксплуатация может дать злоумышленнику полный контроль на уровне root внутри контейнера. Это не означает автоматический выход на хост, но существенно расширяет последствия ошибки конфигурации.
Оценка 9,8 из 10 относится к серверу, доступному по маршрутизируемому адресу. Любой узел, способный подключиться к открытому порту, потенциально может выполнить код без действительных учётных данных. До выхода исправления сервер следует оставлять доступным только на локальной машине либо в доверенной кластерной сети. Доступ к порту нужно ограничить межсетевым экраном. Фильтрация снижает вероятность атаки, но не исправляет ошибку: каждый узел, которому всё ещё разрешено соединение, остаётся потенциальным источником выполнения кода.
LMCache пока не опубликовал собственное уведомление безопасности по CVE-2026-105192. В рекомендациях JFrog также нет способа установить, подвергался ли конкретный сервер атаке. Отдельно пользователь GitHub 6 октября, за день до публичного раскрытия CVE-2026-105192, направил шесть дополнительных сообщений о безопасности LMCache. В них заявлены неаутентифицированный доступ к кэшированным данным других арендаторов и доступ к нескольким сетевым службам, способным выполнять команды без входа в систему. Все шесть сообщений поступили с одной учётной записи, основаны на заявлениях о proof-of-concept, не имеют идентификаторов CVE, подтверждения сопровождающих LMCache или исправлений.
Одно из этих сообщений касается административного HTTP-сервера. В LMCache 0.5.5 он по умолчанию слушал все сетевые интерфейсы, тогда как в кандидатах на выпуск 0.5.6 сервер настроен на прослушивание только локального хоста. Это изменение уменьшает сетевую доступность службы, но не заменяет полноценное исправление остальных проблем.
С LMCache связан отдельный дефект в vLLM: CVE-2026-105756. Он устранён в vLLM 0.30.0, выпущенном 22 сентября. Уязвимыми были версии до 0.30.0 при использовании многопроцессного коннектора LMCache. Один запрос с некорректным значением cache_salt мог привести к падению движка vLLM. Оценка этой проблемы составляет 6,5; она вызывает отказ в обслуживании, но не даёт возможности выполнять произвольный код.
Обе истории укладываются в более широкий класс ошибок, связанный с передачей данных из неаутентифицированного сетевого сокета в механизм десериализации Python pickle. Исследователи обнаружили похожие дефекты в других фреймворках для инференса ИИ в ноябре 2025 года и объединили их под названием ShadowMQ. При этом пока не установлено, происходят ли исходные фрагменты кода LMCache из тех же проектов, в которых нашли уязвимости ShadowMQ.
Изображение носит иллюстративный характер
Проблема возникает в многопроцессном режиме LMCache. В такой конфигурации программа запускается как отдельный сервер кэширования, а рабочие процессы LLM обмениваются с ним данными через библиотеку сообщений ZeroMQ. Специально сформированное сетевое сообщение заставляет сервер выполнить команды, выбранные атакующим. Код запускается с правами пользователя, от имени которого работает процесс LMCache.
Уязвимы версии LMCache от 0.3.9, выпущенной в октябре 2025 года, до 0.5.5, которая считается последним стабильным релизом. Под угрозой остаются также кандидаты на выпуск 0.5.6 и ветка разработки. Патча нет ни для одной из этих версий, поэтому обновление внутри текущего ряда само по себе не устраняет риск.
По умолчанию многопроцессный сервер принимает соединения только на localhost. В таком случае доступ к порту есть лишь у программ на той же машине. Опасная ситуация возникает после настройки прослушивания на маршрутизируемом адресе. Это бывает в многузловых развёртываниях, где несколько машин используют один экземпляр LMCache. Чем шире доступ к сетевому порту, тем больше потенциальных источников атаки.
Особого внимания требует официальный пример развёртывания LMCache в Kubernetes: сервер в нём запускается с прослушиванием на всех сетевых интерфейсах. При такой настройке к нему могут обращаться другие машины и сетевые клиенты. Напротив, экземпляр LMCache, работающий внутри одного процесса vLLM, не открывает уязвимый порт. Описанная проблема относится именно к автономному многопроцессному серверу.
Причина связана с обработкой сообщений ZeroMQ. Сокет, через который рабочие процессы регистрируются на сервере и передают кэшированные данные, не использует аутентификацию. Один из типов сообщений распаковывается средствами Python pickle. Этот формат способен содержать исполняемый код: он запускается уже во время декодирования объекта. LMCache разбирает сообщение при чтении его аргументов, ещё до проверки типа сообщения. Поэтому вредоносная нагрузка может сработать немедленно, до того как сервер поймёт, какую именно команду получил.
Последствия зависят от прав процесса LMCache. Если программа работает с привилегиями обычного пользователя, атакующий получает соответствующий уровень доступа. По данным JFrog, официальные контейнерные образы LMCache запускают процесс от имени root. В таком контейнере успешная эксплуатация может дать злоумышленнику полный контроль на уровне root внутри контейнера. Это не означает автоматический выход на хост, но существенно расширяет последствия ошибки конфигурации.
Оценка 9,8 из 10 относится к серверу, доступному по маршрутизируемому адресу. Любой узел, способный подключиться к открытому порту, потенциально может выполнить код без действительных учётных данных. До выхода исправления сервер следует оставлять доступным только на локальной машине либо в доверенной кластерной сети. Доступ к порту нужно ограничить межсетевым экраном. Фильтрация снижает вероятность атаки, но не исправляет ошибку: каждый узел, которому всё ещё разрешено соединение, остаётся потенциальным источником выполнения кода.
LMCache пока не опубликовал собственное уведомление безопасности по CVE-2026-105192. В рекомендациях JFrog также нет способа установить, подвергался ли конкретный сервер атаке. Отдельно пользователь GitHub 6 октября, за день до публичного раскрытия CVE-2026-105192, направил шесть дополнительных сообщений о безопасности LMCache. В них заявлены неаутентифицированный доступ к кэшированным данным других арендаторов и доступ к нескольким сетевым службам, способным выполнять команды без входа в систему. Все шесть сообщений поступили с одной учётной записи, основаны на заявлениях о proof-of-concept, не имеют идентификаторов CVE, подтверждения сопровождающих LMCache или исправлений.
Одно из этих сообщений касается административного HTTP-сервера. В LMCache 0.5.5 он по умолчанию слушал все сетевые интерфейсы, тогда как в кандидатах на выпуск 0.5.6 сервер настроен на прослушивание только локального хоста. Это изменение уменьшает сетевую доступность службы, но не заменяет полноценное исправление остальных проблем.
С LMCache связан отдельный дефект в vLLM: CVE-2026-105756. Он устранён в vLLM 0.30.0, выпущенном 22 сентября. Уязвимыми были версии до 0.30.0 при использовании многопроцессного коннектора LMCache. Один запрос с некорректным значением cache_salt мог привести к падению движка vLLM. Оценка этой проблемы составляет 6,5; она вызывает отказ в обслуживании, но не даёт возможности выполнять произвольный код.
Обе истории укладываются в более широкий класс ошибок, связанный с передачей данных из неаутентифицированного сетевого сокета в механизм десериализации Python pickle. Исследователи обнаружили похожие дефекты в других фреймворках для инференса ИИ в ноябре 2025 года и объединили их под названием ShadowMQ. При этом пока не установлено, происходят ли исходные фрагменты кода LMCache из тех же проектов, в которых нашли уязвимости ShadowMQ.
