vLLM uses Python 3.12 built-in hash() which leads to predictable hash collisions in prefix cache

Description

Summary

Maliciously constructed prompts can lead to hash collisions, resulting in prefix cache reuse, which can interfere with subsequent responses and cause unintended behavior.

Details

vLLM's prefix caching makes use of Python's built-in hash() function. As of Python 3.12, the behavior of hash(None) has changed to be a predictable constant value. This makes it more feasible that someone could try exploit hash collisions.

Impact

The impact of a collision would be using cache that was generated using different content. Given knowledge of prompts in use and predictable hashing behavior, someone could intentionally populate the cache using a prompt known to collide with another prompt in use.

Solution

We address this problem by initializing hashes in vllm with a value that is no longer constant and predictable. It will be different each time vllm runs. This restores behavior we got in Python versions prior to 3.12.

Using a hashing algorithm that is less prone to collision (like sha256, for example) would be the best way to avoid the possibility of a collision. However, it would have an impact to both performance and memory footprint. Hash collisions may still occur, though they are no longer straight forward to predict.

To give an idea of the likelihood of a collision, for randomly generated hash values (assuming the hash generation built into Python is uniformly distributed), with a cache capacity of 50,000 messages and an average prompt length of 300, a collision will occur on average once every 1 trillion requests.

References

  • https://github.com/vllm-project/vllm/pull/12621
  • https://github.com/python/cpython/commit/432117cd1f59c76d97da2eaff55a7d758301dbc7
  • https://github.com/python/cpython/pull/99541

Basic information

Type
reviewed
Severity
low
Advisory on GitHub
Open advisory ↗
Repository advisory
Open repository advisory ↗
Source code
Browse source ↗
Published (advisory)
2025-02-06 20:00:05 UTC
Updated
2025-07-02 14:20:35 UTC
GitHub reviewed
2025-02-06 20:00:05 UTC
NVD published
2025-02-07

EPSS Score

Score Percentile
0.32% 55.27%

CVSS Scores

Base score Version Severity Vector
2.6 3.1
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:N/I:L/A:N Click to expand
Attack vector (AV:N)
Could be attacked over the internet or any normal routed network—not just someone sitting at the machine.
Attack complexity (AC:H)
Even with access, the exploit needs extra luck, timing, or a fussy environment to actually work.
Privileges required (PR:L)
A normal user session is enough; they don’t have to be admin.
User interaction (UI:R)
A real person has to do something—click, install, enable—otherwise it doesn’t land.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:L)
Attackers could change some data, but it’s limited—not everything goes.
Availability (A:N)
Service keeps running; no real outage angle.

Identifiers

CWEs

CWE id Name
CWE-354 Improper Validation of Integrity Check Value

Credits

  • kexinoh (reporter)
  • russellb (coordinator)

Affected packages (1)

Vulnerable version ranges and first patched releases as published by GitHub.

Ecosystem Package Vulnerable range First patched Vulnerable functions
pip vllm < 0.7.2 0.7.2

References

cvelogic Threat Intelligence