Критическая уязвимость в LMCache: удалённый код без авторизации и без патча
Компания JFrog 7 октября сообщила о критической уязвимости в LMCache — свободном программном обеспечении, которое ускоряет работу серверов больших языковых моделей, в частности vLLM. Брешь получила оценку 9,8 из 10 и идентификатор CVE-2026-105192. Исправленной версии на момент раскрытия не существует.
Где прячется дыра
Проблема связана с многопроцессным режимом LMCache, в котором кэш работает как отдельный сервер, а рабочие процессы модели обращаются к нему через библиотеку обмена сообщениями ZeroMQ. Сокет, который сервер открывает для регистрации процессов и обмена кэшированными данными, не требует никакой аутентификации. Один из типов сообщений распаковывается с помощью pickle — формата Python, способного переносить и выполнять код прямо в момент декодирования. Сервер разбирает сообщение ещё до проверки его типа, поэтому специально составленное сообщение запускает код отправителя.
Код выполняется с привилегиями процесса LMCache. На официальных контейнерных образах проекта, по данным JFrog, этот процесс работает от имени root. Уязвимость обнаружил Юваль Моравчик из исследовательской группы JFrog.
Опасно не везде
Всё решает одна настройка. По умолчанию многопроцессный сервер слушает только локальную машину, и дотянуться до него извне нельзя. Он становится доступен, лишь когда оператор запускает его на маршрутизируемом адресе — как это бывает при распределённых установках, где кэш общий для нескольких узлов. Именно так поступает пример развёртывания в Kubernetes, поставляемый вместе с LMCache: сервер слушает все сетевые интерфейсы. При этом LMCache внутри одного процесса vLLM порт вообще не открывает.
Уязвимы версии с 0.3.9 (октябрь 2025 года) по текущую стабильную 0.5.5, а также кандидаты в релиз 0.5.6 и ветка разработки.
Что делать
Исправления нет. До его выхода JFrog советует не присваивать многопроцессному серверу маршрутизируемый адрес и держать порт на локальной машине либо в доверённой сети кластера. Межсетевой экран снижает риск, но не устраняет его: любой узел, способный открыть соединение, сможет выполнить код. Собственного бюллетеня безопасности LMCache пока не опубликовал, а способа понять, был ли сервер уже атакован, в рекомендациях JFrog нет.
Отдельно 6 октября один из пользователей GitHub подал ещё шесть сообщений о проблемах в LMCache, включая якобы несанкционированный доступ к чужим данным. Все они исходят из единственного аккаунта, опираются на proof-of-concept и не подтверждены сопровождающими. Кроме того, уже устранена связанная уязвимость в vLLM (CVE-2026-105756, оценка 6,5): до версии 0.30.0 запрос с неправильным значением cache_salt мог обрушить движок.
Корневая ошибка — передача данных из неаутентифицированного сокета в pickle — та же, что исследователи находили в других фреймворках вывода ИИ ещё в ноябре 2025 года в группе брешей под названием ShadowMQ.
Источник: The Hacker News
Комментарии
Войдите, чтобы комментировать.