CVE-2026-10813
Use of Weak Hash in LMCache up to 0.4.6
Publication date: 2026-06-04
Last updated on: 2026-06-04
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| lmcache | lmcache | to 0.4.6 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-328 | The product uses an algorithm that produces a digest (output value) that does not meet security expectations for a hash function that allows an adversary to reasonably determine the original input (preimage attack), find another input that can produce the same hash (2nd preimage attack), or find multiple inputs that evaluate to the same hash (birthday attack). |
| CWE-327 | The product uses a broken or risky cryptographic algorithm or protocol. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in LMCache involves hash collisions that can lead to cache poisoning, causing incorrect cached data to be returned and potential exposure of cross-user visual context.
This exposure of private image context could impact confidentiality requirements under regulations such as GDPR and HIPAA, which mandate protection of personal and sensitive data.
Although the attack requires local access and has a high complexity, the potential for leaking private data through incorrect cache responses may pose compliance risks related to data privacy and integrity.
Organizations using LMCache in environments subject to these regulations should consider the risk of data leakage and implement mitigations or updates to address the vulnerability.
How can this vulnerability impact me? :
This vulnerability can impact you by causing incorrect outputs from the LMCache system due to cache poisoning. When hash collisions occur, the system may return cached data associated with one image for a different image request, leading to incorrect model outputs.
There is also a potential medium confidentiality risk because private visual context from one user could be exposed to another user through these collisions.
The availability of the service is not significantly affected, as the system remains operational despite the flaw.
The attack complexity is high and requires local access, but once exploited, it can manipulate cached responses and cause integrity and confidentiality issues.
Can you explain this vulnerability to me?
The vulnerability CVE-2026-10813 is a flaw in LMCache's multimodal caching mechanism, specifically in the function hex_hash_to_int16 in the file lmcache/integration/vllm/utils.py. This function reduces multimodal identifiers, such as image hashes, to a 16-bit value, which only allows for 65,536 possible hash values.
Because of this limited range, different images can produce the same 16-bit hash, leading to hash collisions. These collisions cause incorrect cache key generation, resulting in cache poisoning where the system may return cached data from one image for a request involving a different image.
This flaw can be exploited by generating many distinct image identifiers and observing collisions after a few hundred inputs due to the birthday paradox. The attack requires local access and has a high complexity, but the exploit has been published.
A practical fix involves expanding the hash size from 16 bits to at least 64 bits to increase entropy and prevent collisions.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
The vulnerability involves hash collisions caused by the function hex_hash_to_int16 in LMCache, which reduces multimodal identifiers to a 16-bit hash. Detection involves monitoring for unusual cache key collisions or incorrect cached data being returned for different image inputs.
One practical approach is to generate many distinct image identifiers and observe if collisions occur after a few hundred inputs, indicating the weak 16-bit hash function is in use.
Since the attack vector can be network-accessible in deployments handling multimodal requests, network monitoring tools could be used to detect abnormal cache behavior or repeated cache key collisions.
Specific commands are not provided in the resources, but you might consider using debugging or logging within LMCache to track cache key generation and collisions, or use scripts to simulate multiple distinct inputs and check for cache poisoning effects.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation involves updating LMCache to use the fixed implementation that replaces the 16-bit hash function with a 64-bit hash function, significantly reducing the risk of collisions.
This fix is available as a pull request that expands the hash entropy from 16 bits to 64 bits by replacing the hex_hash_to_int16 function with hex_hash_to_int64.
Until the fix is accepted and deployed, consider limiting local access to the vulnerable function or component, as the attack requires local execution and high complexity.
Monitoring for suspicious cache collisions and restricting the number of distinct multimodal inputs processed in a short time frame may also help reduce exploitation risk.