CVE-2026-10813: LMCache Weak Hash Vulnerability in KV Cache Handler

Technical summary

CVE-2026-10813 involves improper cryptographic hash handling in the hex_hash_to_int16 function within lmcache/integration/vllm/utils.py. The vulnerability allows manipulation of hash values through the KV (key-value) cache handler, leading to use of weak or predictable hashing. The attack surface is local-only, requires low-level privileges, and demands high attack complexity. This maps to CWE-327 (Use of a Broken or Risky Cryptographic Algorithm) and CWE-328 (Use of Insufficiently Random Values).

Business impact

The integrity of cached key-value pairs in LLM inference pipelines could be compromised, potentially leading to incorrect model outputs or denial of service in compute-intensive workloads. For organizations deploying LMCache in multi-tenant or sensitive inference scenarios, this could affect model reliability and data consistency. The local-only requirement and high complexity threshold mean impact is confined to insider threats or supply-chain scenarios rather than broad external risk.

Affected systems

LMCache through version 0.4.6 is affected. The vulnerability resides in the KV Cache Handler component used during vLLM integration. Any deployment using LMCache for optimization of large language model inference with version 0.4.6 or earlier is in scope. Verify your LMCache version via pip show lmcache or your deployment manifests.

Exploitability

Exploitation requires local system access, authenticated user privileges, and substantial technical knowledge of the cache internals and cryptographic logic. Public exploit code exists but weaponization remains non-trivial due to high attack complexity. The barrier to exploitation effectively limits this threat to privileged insiders, compromised development environments, or targeted attacks rather than mass exploitation campaigns.

Remediation

Upgrade LMCache to a patched version released after June 2026 that includes the accepted pull request fixing the hex_hash_to_int16 function. Organizations should verify patch availability from the LMCache project maintainers before upgrading. Until patching is possible, restrict local system access to LMCache deployments and monitor for unauthorized hash manipulation attempts.

Patch guidance

A pull request addressing this vulnerability is under acceptance review. Monitor the LMCache repository (verify against the vendor advisory) for release of a patched version beyond 0.4.6. Apply the update promptly to all LMCache installations, particularly in environments handling sensitive inference workloads. Test patched versions in non-production environments first to ensure compatibility with your vLLM deployment.

Detection guidance

Monitor system logs for local user access to LMCache processes and the vllm/utils.py module. Implement integrity checking on the KV cache storage layer to detect unexplained hash value changes. In development environments, enforce code review practices for any modifications to cryptographic functions. Consider canary deployments or anomaly detection on cache hit/miss ratios as an indirect signal of hash manipulation.

Why prioritize this

While this vulnerability carries a low CVSS score (3.6), it should not be deprioritized entirely. The combination of published exploit code, weak cryptography, and integrity impact warrants inclusion in patch cycles. However, organizations without multi-tenant LMCache deployments or strict data integrity requirements may defer this below critical infrastructure vulnerabilities. Prioritize if: (1) you run inference services on shared systems, (2) you have privileged users with security concerns, or (3) cache integrity is audit-relevant.

Risk score, explained

The CVSS 3.1 score of 3.6 (LOW) reflects: local-only attack vector (AV:L), high attack complexity (AC:H), low privilege requirement (PR:L), no user interaction needed (UI:N), single security zone (S:U), no confidentiality impact (C:N), but integrity and availability impacts (I:L, A:L). The score appropriately downgrades risk due to access and complexity barriers; however, the existence of public exploits elevates practical concern slightly above the numerical rating.

Frequently asked questions