CVE-2026-100647 is a Medium (CVSS 5.3) denial of service in vLLM before 0.29.0. An unauthenticated attacker can send a request with a very large cache_salt value and stall the scheduler for everyone. Upgrade to 0.29.0 or later and limit request body size at your gateway.
What's affected
vLLM versions before 0.29.0 are affected, per the record and the GitHub advisory, which lists patched versions as 0.29.0 and later. The weakness is CWE-20 (improper input validation), because the cache_salt field has no maximum length.
According to the GitHub advisory, the field is accepted on the OpenAI compatible chat completions, completions, responses and pooling endpoints and on the Anthropic messages endpoint. It is checked only for a minimum length. The full value is hashed on the single EngineCore scheduler thread, so a very large value makes that thread spend its time on serialization and hashing instead of serving requests.
The advisory reports measurements on a live server. A 10 MB salt added about 58 ms of request latency, a 100 MB salt about 599 ms, and a 200 MB salt about 1195 ms, against a baseline near 9 ms. Under six concurrent attackers sending 100 MB salts, ordinary requests were stalled for around 1.8 seconds at the 90th percentile. It notes that no HTTP request body limit applies by default.
The advisory rates it Moderate, which agrees with the record's Medium score of 5.3.
How to check if you're exposed
Check the installed version.
pip show vllm
If it reports a version before 0.29.0, you are in scope. In a container, run the same command inside the image, or read the version from the image tag and the build record.
Next, look at exposure. The attacker needs network access to the API and no authentication. A server bound to localhost behind an authenticating gateway is less exposed than one listening on a public address. Check whether your gateway enforces a maximum request body size, since the advisory says vLLM does not apply one by default.
The free in-browser dependency scan at gold.safeguard.sh/scan can match a lockfile or manifest against known CVEs without installing anything. The Gold directory page for each CVE lists affected packages and fixes as they are published.
What to do now
- Upgrade vLLM to 0.29.0 or later.
- Set a maximum request body size on the reverse proxy or API gateway in front of vLLM.
- Require authentication before requests reach the model server, so anonymous clients cannot use these endpoints.
- Watch request latency and request size in your monitoring for sudden spikes.
- Rebuild container images so that the updated package is what ships.
Why it matters
This is a resource exhaustion flaw rather than a data theft one. The weakness is a missing bound on user input that lands on a single shared thread. Because that thread serves every client, one noisy request source can degrade service for all tenants.
For teams that run a model server on shared infrastructure, availability is part of the product. The record does not mark the CVE as known exploited. The fix is small, and a size cap at the proxy is a sound control whatever the version.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this need authentication?
No. The advisory says no authentication, feature flag or control plane access is required, which is why gateway controls matter.
Is the Medium rating reasonable?
It affects availability only, per the record vector, and the GitHub advisory also rates it Moderate. For a public facing model server that is still worth fixing quickly.
Sources
Last reviewed: 18 October 2026.
