Віддалене виконання коду у LMCache: ризик для LLM‑кластерів і multi-tenant середовищ

Критична вразливість 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, а технічний розбір наведений у бюлетені безпеки 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 advisories, і виправлений реліз відсутній. Експлуатація вразливості «в дикій природі» в вихідному матеріалі не фіксується, але вектор атаки тривіальний, не вимагає автентифікації й не прив’язаний до конкретної версії Python або ZeroMQ, що робить практичну експлуатацію вкрай реалістичною.

Контекст загроз: повторюваний шаблон ShadowMQ

Дослідники JFrog зазначають, що логічна помилка збігається з раніше виявленою серією вразливостей в інфраструктурі AI‑інференсу, які отримали умовну назву ShadowMQ: дані з неавтентифікованого мережевого сокета напряму передаються на десеріалізацію через pickle. Це не поодинока помилка конкретного проєкту, а сталий анти‑патерн у дизайні високопродуктивних IPC та мережевих компонентів в AI‑стеці.

Показово, що LMCache не є єдиним компонентом ланцюжка. В екосистемі vLLM уже виправлена окрема вразливість відмови в обслуговуванні CVE-2026-105756, за якої одиничний запит із некоректним значенням cache_salt міг аварійно завершувати рушій за використання конектора LMCache multiprocess. Докладніше в бюлетені безпеки проєкту 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;
  • вимкнути зайві capabilities ядра й доступ до hostPath‑томів.
• Увімкніть контроль поведінки контейнерів (seccomp, AppArmor або аналогічні механізми), щоб обмежити системні виклики й ускладнити постексплуатацію.

3. Патчі та версії супутніх компонентів

• Оновіть vLLM до версії 0.30.0 або новішої, щоб усунути вразливість DoS CVE-2026-105756 у LMCache‑конекторі (бюлетень безпеки vLLM).
• Стежте за виходом виправленого релізу LMCache в розділі security advisories і в документації multiprocess mode; заплануйте прискорене оновлення, щойно патч стане доступним.

4. Моніторинг та індикатори можливої експлуатації

JFrog не публікує явних індикаторів компрометації (IP‑адреси, хеші шкідливих образів тощо), але можна вжити таких заходів:

• Аналізувати журнали мережі та Kubernetes на предмет:
  • підключень до порту multiprocess‑сервера LMCache з нетипових підмереж або namespace;
  • аномального зростання кількості реєстрацій воркерів або неочікуваних перезапусків подів з LMCache.
• Перевірити вузли, де працює LMCache, на:
  • наявність невідомих процесів і cron‑завдань;
  • зміни в контейнерних образах, томах з конфігурацією та бінарних файлах.
• Увімкнути додатковий аудит команд і системних викликів контейнерів LMCache до виходу офіційного виправлення.

Критичний висновок: до появи патча до CVE-2026-105192 єдиним реальним захистом залишається жорстке обмеження мережевого доступу до multiprocess‑сервера LMCache та відмова від запуску його з привілеями root; першим кроком має стати інвентаризація всіх розгортань LMCache і негайне перепідключення ZeroMQ‑сокета до локальних або суворо контрольованих сегментів мережі.