CVE-2026-100652 is a Medium (CVSS 5.9) denial of service in vLLM 0.22.0 through 0.23.0. Out of range stop_token_ids sent to the Rust HTTP or gRPC frontend can crash the EngineCore. The GitHub advisory lists 0.24.0 as the patched version. Upgrade to 0.24.0 or later.
What's affected
The record says vLLM versions 0.22.0 through 0.23.0 are affected. The GitHub advisory agrees on the affected range and names 0.24.0 or later as patched. The record itself gives no fixed version, so the advisory is the source for that number. The weakness is CWE-20 (improper input validation).
According to the advisory, the Rust HTTP and gRPC frontends do not check stop_token_ids against the vocabulary size. Out of vocabulary token IDs then reach the min tokens logits processor. When min_tokens is greater than zero, those IDs are used as CUDA tensor indices, which triggers a device side assertion and leaves the EngineCore in a fatal state that needs a restart.
The advisory calls this a sibling call site of an earlier fix. A change to the Python request path added the missing check there, but the Rust paths still forwarded the values. The advisory rates it Moderate, which matches the record's Medium 5.9.
How to check if you're exposed
Check the version.
pip show vllm
If the result is 0.22.0 through 0.23.0, you are in range. Then check whether you use the Rust HTTP or gRPC frontend, since that is the path the advisory describes. If you serve only through the Python frontend on these versions, the Rust specific condition may not apply, but upgrading removes the question.
Look at reliability signals as well. Unexpected EngineCore restarts or CUDA device side assertion errors in your logs after requests with unusual stop token values are worth a closer look.
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.24.0 or later. Moving to 0.29.0 or later also covers CVE-2026-100647, which is fixed there.
- Place an authenticating gateway in front of the model server so anonymous clients cannot set sampling parameters.
- Validate or strip stop_token_ids at the gateway if you expose them to untrusted users.
- Alert on EngineCore restarts and CUDA assertion errors.
- Rebuild images and redeploy so the new version is what runs.
Why it matters
Machine learning serving stacks accept many numeric parameters from callers. When one of them indexes into a tensor without a bounds check, a bad value does more than fail one request. On a GPU, a device side assertion can leave the whole engine unusable until it restarts.
Fixing the same flaw in one code path and missing it in another is common, and the advisory itself says so. The practical lesson is to validate at the API boundary for every frontend you run. The record does not mark the CVE as known exploited.
Quick check
Which versions are affected?
Versions 0.22.0 through 0.23.0, per the record and the GitHub advisory. The advisory lists 0.24.0 or later as patched.
Does it need authentication?
The record does not say that credentials are required. Assume anyone who can reach the API can try it, and put authentication in front of the server.
Sources
Last reviewed: 18 October 2026.
