CVE-2026-100652 vllm-project CVE debrief

Who should care

Defenders responsible for deploying and managing vLLM should assess exposure and prioritize patching or mitigation to prevent potential denial-of-service attacks. This includes reviewing the current version of vLLM in use, verifying if it falls within the affected range (0.22.0 through 0.23.0), and taking appropriate actions to secure the system. Additionally, defenders should ensure that input validation and sanitization for stop_token_ids are properly in

Why it matters

A denial-of-service vulnerability in vLLM versions 0.22.0 through 0.23.0 can be exploited by submitting malicious requests, potentially disrupting service availability. Defenders should prioritize verifying affected versions and applying patches or mitigations to prevent exploitation.

• Denial-of-service attacks can be launched by submitting malicious requests, potentially disrupting service availability.
• Defenders need to verify affected versions and apply patches or mitigations to prevent exploitation.
• The vulnerability requires verification of input validation and sanitization for stop_token_ids to prevent out-of-vocabulary token IDs from reaching MinTokensLogitsProcessor.
• Service restart may be required to recover from a fatal state in EngineCore.

Technical summary

The vulnerability exists in vLLM versions 0.22.0 through 0.23.0, where the failure to validate stop_token_ids against vocabulary bounds in Rust HTTP and gRPC frontends allows out-of-vocabulary token IDs to reach MinTokensLogitsProcessor. This can be exploited by submitting requests with min_tokens greater than zero and out-of-vocabulary stop_token_ids, triggering CUDA tensor indexing failures that leave EngineCore in a fatal state requiring service restart.

Defensive priority

Defenders should prioritize verifying affected versions and applying patches or mitigations to prevent potential denial-of-service attacks.

Recommended defensive actions

• Verify if the vLLM version is within the affected range (0.22.0 through 0.23.0) and apply patches or mitigations as needed.
• Implement input validation and sanitization for stop_token_ids to prevent out-of-vocabulary token IDs from reaching MinTokensLogitsProcessor.
• Monitor for potential denial-of-service attacks and adjust security controls accordingly.
• Review compensating controls for exposed systems while remediation is scheduled and verified.
• Check relevant monitoring, detection, and logs for exposed assets that need extra review.
• Track exceptions, retest remediated assets, and close the item only after evidence is documented.
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up.

Evidence notes

The vulnerability is caused by a failure to validate stop_token_ids against vocabulary bounds in Rust HTTP and gRPC frontends. This allows out-of-vocabulary token IDs to reach MinTokensLogitsProcessor, triggering CUDA tensor indexing failures.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.