NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐍
🐍 PyPI
Not in CISA KEV
LOW severity

vLLM uses Python 3.12 built-in hash() which leads to predictable hash collisions in prefix cacheGHSA-rm76-4mrf-v9r8

LOWFix: python/cpython#99541

GHSA-rm76-4mrf-v9r8 is a low-severity (CVSS 2.6) CWE-354 vulnerability in vllm. A fix is available for vllm — see the affected versions and patch details below.

Also known asCVE-2025-25183PYSEC-2025-62
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-rm76-4mrf-v9r8.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs9th percentile — riskier than 9% of all scored CVEsHighest risk
0.00%0.27%0.55%0.82%0.3%0.2%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🐍vllm

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.

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

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐍PyPIvllmall versions0.7.2pip install --upgrade 'vllm==0.7.2'

Affected Products

1 product · 1 configurations
Application
vllmvllm
< 0.7.2
range

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for vllm, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update vllm to 0.7.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-rm76-4mrf-v9r8 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatLow
Workaround published by Red Hat
Using a hashing algorithm that is less prone to collision, such as sha256, for example, would be the best way to avoid the possibility of a collision.
Source: Red Hat security advisory for GHSA-rm76-4mrf-v9r8 (CC BY 4.0)

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is GHSA-rm76-4mrf-v9r8 in your dependencies?

Find it across PyPI, including transitive dependencies.

Scan my dependencies How O3 SCA works
vLLM uses Python 3.12 built-in hash() which leads to…