--host is a routable address, and the official images still run the process as root.The LMCache contributor team and community are pleased to announce LMCache v0.5.6, released on October 14. It includes a critical security fix, wider hardware support, and SGLang integration. It also includes other security and bug fixes, and new features.
LMCache 0.5.6 fixes CVE-2026-105192, a critical vulnerability in multiprocess (MP) mode. In versions 0.3.9 through 0.5.5, a single unauthenticated network message to the MP server’s port (5555 by default) could run arbitrary code as the LMCache process user.
The official container images run that process as root. The advisory rates the flaw 9.8 on the Common Vulnerability Scoring System (CVSS). An attacker needs only network access, with no authentication and no user interaction.
The fix for CVE-2026-105192
The fix replaces pickle in MP device inter-process communication (IPC) descriptors with versioned, typed MessagePack descriptors. It covers both the ZeroMQ and gRPC transports.
Because the wire format changed, 0.5.6 cannot communicate with earlier versions.
Important: Upgrade all MP workers and servers at the same time.
Only MP mode is affected. Using LMCache inside the vLLM process does not open the port.
The MP port binds to localhost by default. It is exposed when --host is set to a routable address.
The example Kubernetes deployment binds to all interfaces, so deployments based on it are exposed. In 0.5.7, the example will bind to localhost. Until then, keep the MP transport on localhost or on a trusted cluster network, and restrict access to port 5555 with firewall rules or network policies.
The release candidates 0.5.6rc1 to rc3 are also affected.
Yuval Moravchick of JFrog Security Research reported the issue. It was disclosed publicly on October 7, before a patched version existed.
Our October 13 post and the security advisory explain how the flaw works, give the timeline, and describe how to check a deployment for compromise.
What the fix covers
Each descriptor is now validated before use, with the device wrapper type coming from a fixed local allowlist and no pickle fallback. Details for the fix are in PR #5644.
Some work remains. The fix covers MP device IPC descriptors only. The engine-driven path, which is off by default, still uses pickle. Before 0.5.8, we plan to remove pickle from that path.
MP mode does not yet authenticate remote procedure calls (RPC) between the server, the MP coordinator, and the frontend. RPC authentication is planned for 0.5.7.
Upgrade notes for operators
Version 0.5.6 also changes two admin defaults. Both changes (#5129, by Aleksander Pejcic) merged on September 22, before the disclosure, so they are separate from the CVE fix.
Before 0.5.6, POST /run_script was served on all network interfaces with no authentication. This endpoint runs caller-supplied Python inside the LMCache process.
Now /run_script returns 404 unless you set run_script_api_enabled or --run-script-api-enabled. When you enable it, it still has no authentication. The docs say to “treat it as full remote code execution.”
The admin HTTP servers now bind to 127.0.0.1 instead of 0.0.0.0. The settings for this are internal_api_server_host and --http-host.
Before you upgrade, check these points:
- Upgrade all MP workers and servers together, because the wire format changed.
- If you use
/run_script, setrun_script_api_enabledor--run-script-api-enabled. - Admin HTTP binds to
127.0.0.1. For admin access across nodes, set the bind host explicitly. - Official images still run as root in 0.5.6. To run as non-root now, build your own image from the Dockerfile, or wait for 0.5.7.
- RPC authentication is planned for 0.5.7. Until then, keep the MP server, coordinator, and frontend on a trusted network.
SGLang integration
LMCache 0.5.6 adds a new SGLang integration, built on SGLang’s unified radix cache (#4828, by chunxiaozheng). SGLang connects to a standalone LMCache MP server.
SGLang keeps its radix tree and its KV cache on the GPU. LMCache manages the CPU and remote cache tiers outside SGLang. When a prefix is not on the GPU, SGLang asks the LMCache server to look it up and retrieve it, and it sends new KV cache to the server to store.
Lookup and prefetch are asynchronous. If one tensor-parallel (TP) or pipeline-parallel (PP) rank fails, all ranks make the same choice, so the ranks stay consistent.
The integration uses the same transfer modes as the vLLM connector. LMCache-driven transfer is the default on CUDA. Engine-driven transfer (#5549) is new for SGLang in this release. It supports one transfer group, so hybrid models must use auto or lmcache_driven.
#5379 adds support for DeepSeek-V4.1-Flash. For hybrid models, start the LMCache server with --separate-object-groups. Without it, LMCache can restore incompatible KV or state data and cause accuracy problems.
The integration requires a version of SGLang that includes SGLang PR #38652. It runs only in MP mode, so the CVE-2026-105192 fix and the upgrade notes above apply to SGLang deployments too.
A minimal setup has a configuration file, an LMCache server, and an SGLang server:
cat > lmcache_config.yaml <<'EOF'mp_host: 127.0.0.1mp_port: 5555EOFlmcache server --host 127.0.0.1 --port 5555 \ --l1-size-gb 10 --eviction-policy LRU --supported-transfer-mode autopython -m sglang.launch_server --model-path Qwen/Qwen3-8B \ --enable-lmcache --lmcache-config-file "$PWD/lmcache_config.yaml"
The new lmcache/sglang image (#5590, by aeon-x) is the official SGLang release image with the matching LMCache wheel installed. Run it with --enable-lmcache against a separate LMCache server, such as lmcache/standalone. The image build fails if SGLang and LMCache need different torch versions, or if the SGLang connector does not load.
Hardware and software in this release
Many changes in 0.5.6 add or improve support for specific hardware, storage systems, and inference engines. The two tables below list them with their pull requests.
| Hardware | New or improved in 0.5.6 | Pull requests |
|---|---|---|
| NVIDIA GPUs (CUDA) | Faster LMCache-driven transfers with cudaMemcpyBatchAsync; CUDA 12.9 builds for arm64 | #5308, #5365 |
| AMD GPUs (ROCm) | Direct copy-engine transfer; pending HIP errors cleared after host memory registration | #5358, #5565 |
| Intel GPUs (XPU) | Native SYCL block transfer; pinned-memory backend | #5408, #5311 |
| Ascend NPUs | NPU platform backends for LMCache-driven transfer; a KV format for vLLM-Ascend MLA | #5341, #5138 |
| MUSA GPUs | SmartIO muFile backend for MP GDS L1 | #5027 |
| RBLN NPUs | Block transfer for MLA; MP smoke tests in CI | #4726, #5543 |
| MetaX MACA | CI pipeline on MACA hardware | #4949 |
| arm64 hosts | Docker images, plus CUDA 12.9 wheels and images | #5337, #5365 |
| Engines, storage, and platforms | New or improved in 0.5.6 | Pull requests |
|---|---|---|
| vLLM | MP server autostart from the connector; per-request offload limit; MP lookup latency metric; support for the vLLM 0.26.0 fused KV cache layout | #3476, #5029, #5024, #4253 |
| SGLang | Unified LMCache radix cache; engine-driven transfer; DeepSeek-V4.1-Flash support; new lmcache/sglang image | #4828, #5549, #5379, #5590 |
| 3FS | Native L2 storage backend | #5131 |
| NIXL | Native connector; IBM_SCALE backend support | #4865, #5170 |
| DRAM, Device-DAX, GDS | Multi-L1 serving across DRAM, Device-DAX, and GPUDirect Storage (GDS); Device-DAX reconfiguration at runtime | #5416, #5461, #5077 |
| RawBlock (io_uring) | Fixed-buffer I/O for MP L1 memory; batched recovery reads | #4413, #4164 |
| Kafka | Cache-event sink and source for the coordinator | #5285, #5286 |
| Kubernetes operator | runtimeClassName override; NRI and CDI docs | #5057 |
| NVIDIA Dynamo | Local and Kubernetes integration guide | #5257 |
Fail-closed session locks
#5457 makes free_lookup_locks fail closed. The release notes list it with the security hardening changes, because it protects a shared engine from failures that one request can cause.
Before this fix, a session could expire when its request was waiting in the vLLM queue. Then free_lookup_locks released read locks that other requests still held.
Those other requests failed to retrieve their data. On hybrid models with several KV cache groups, that failure stops the engine. One expired session could stop serving for every request on that engine.
In the reported case, a Kimi-K3 deployment on eight MI355X GPUs ran an agentic trace at a concurrency of 70. It logged about 1,000 lock warnings, and the engine stopped after about 25 minutes.
Now, when a session has expired, free_lookup_locks releases none of its read locks. The L1 read time-to-live (TTL) releases them later.
The new --session-ttl-seconds flag sets the session lifetime, which was fixed at 600 seconds before. The default is still 600 seconds. Raise it if requests can wait longer than that between lookup and retrieval, for example in deep vLLM queues.
Thanks to Hyukjoon Lee for the fix.
Builds and images
LMCache now publishes arm64 Docker images, plus CUDA 12.9 wheels and images for arm64. Version 0.5.5 already published aarch64 (arm64) wheels.
The lmcache/vllm-openai:v0.5.6 image supports both amd64 and arm64. A new lmcache/sglang image is also available.
To install or upgrade the Python package:
pip install -U lmcache
Other changes
The platform layer was refactored. Device code now lives under platform/devices, and the legacy CUDA package was removed.
GDS, IPC, and pointer operations now go through the platform layer. The legacy vLLM MP connector snapshots were removed.
Other highlights:
- Prefetch controller v2.
- MP mode: preemption, eviction-aware lazy offload, ARC eviction, a gRPC transport, pluggable server modules, and 2 MiB hugepages.
- Coordinator: record and replay of event traces.
- CacheBlend: Re-RoPE in fp8 (e4m3 and e5m2), reorder logic changes, and whole-chunk L2 loading.
- Faster startup, from batched recovery validation and a faster CLI.
The release notes list every change with its pull request. Their “Coming in v0.5.7” section lists changes that merged after the v0.5.6 tag was created. These changes are in nightly builds now, and they will be in 0.5.7.
Thank you, new contributors
This release includes work from 48 new contributors, all named in the release notes. Many first contributions came from the change to lazy %-format logging.
About 25 commits converted log calls, and 12 of those were issues marked “good first issue.” Welcome, and thank you.
Questions and feedback
If you have questions, ideas, or concerns about this release, open a new Discussion or Issue on GitHub.
To report a security vulnerability, do not use a public Discussion or Issue. Follow the security policy and report it privately.
