CVE-2026-55514 Overview
CVE-2026-55514 is a denial-of-service vulnerability in vLLM, an open-source library for large language model (LLM) inference and serving. Versions from 0.12.0 up to (but not including) 0.24.0 fail an internal assertion when a /v1/completions request contains a pure prompt_embeds payload against a model using Multimodal Rotary Position Embedding (M-RoPE). The failed assertion crashes the EngineCore process and terminates the entire server. Any authenticated remote user permitted to submit completion requests can trigger the crash. The issue is classified under CWE-617: Reachable Assertion and is fixed in vLLM 0.24.0.
Critical Impact
A single crafted /v1/completions request from any authorized user can shut down a vLLM inference server, disrupting all downstream LLM-dependent services.
Affected Products
- vLLM 0.12.0 through versions prior to 0.24.0
- Deployments serving models that use M-RoPE (Multimodal Rotary Position Embedding)
- Any application or API gateway exposing vLLM's /v1/completions endpoint
Discovery Timeline
- 2026-07-06 - CVE-2026-55514 published to NVD
- 2026-07-07 - Last updated in NVD database
Technical Details for CVE-2026-55514
Vulnerability Analysis
vLLM exposes an OpenAI-compatible HTTP API. The /v1/completions endpoint accepts either tokenized prompts (prompt_token_ids) or precomputed embedding tensors (prompt_embeds). When a request supplies only prompt_embeds and the loaded model uses M-RoPE, vLLM's GPU model runner attempts to initialize multimodal rotary positions for the request.
The initialization code in _init_mrope_positions asserts that req_state.prompt_token_ids is not None. Pure embedding submissions legitimately have no token IDs, so the assertion fails. Because the assertion runs inside the EngineCore worker process, the raised AssertionError propagates and terminates the process, taking the entire server down. All in-flight requests fail and the service must be restarted.
Root Cause
The root cause is an incorrect precondition check that treats prompt_token_ids as mandatory for M-RoPE initialization. vLLM already supports prompt_embeds as a passthrough modality without a grid_thw tensor, but the M-RoPE path did not account for that branch. The assertion becomes reachable through normal, well-formed API input, satisfying CWE-617.
Attack Vector
An attacker authenticates to the vLLM API with any account permitted to call /v1/completions. The attacker submits a completion request whose body contains a prompt_embeds tensor and no prompt or prompt_token_ids field, targeting a served model that uses M-RoPE. The server invokes _init_mrope_positions, the assertion fails, and EngineCore crashes. The attacker can repeat the request after any restart to sustain the denial of service.
def _init_mrope_positions(self, req_state: CachedRequestState):
model = self.get_model()
assert supports_mrope(model), "M-RoPE support is not implemented."
- assert req_state.prompt_token_ids is not None, (
- "M-RoPE requires prompt_token_ids to be available."
- )
mrope_model = cast(SupportsMRoPE, model)
# `prompt_embeds` is a passthrough modality (no grid_thw), models'
Source: vLLM security patch commit 470229c. The patch removes the mandatory prompt_token_ids assertion so the M-RoPE path tolerates pure embedding inputs.
Detection Methods for CVE-2026-55514
Indicators of Compromise
- Unexpected EngineCore process termination in vLLM logs, often preceded by an AssertionError referencing _init_mrope_positions or prompt_token_ids.
- Repeated HTTP 5xx responses from /v1/completions immediately after receiving a request carrying a prompt_embeds field.
- Container or systemd restart loops on vLLM inference workers correlated with a single client source IP.
Detection Strategies
- Enable vLLM verbose logging and alert on stack traces containing AssertionError from vllm/v1/worker/gpu_model_runner.py.
- Inspect API gateway or reverse proxy logs for /v1/completions requests whose JSON body contains prompt_embeds but omits prompt and prompt_token_ids.
- Correlate inference worker crash events with request identifiers to attribute the triggering client.
Monitoring Recommendations
- Track process uptime and restart counts for vLLM worker containers; sudden regressions indicate active exploitation.
- Monitor request-rate anomalies from individual API keys, especially low-volume clients producing high crash rates.
- Forward vLLM stdout/stderr and Kubernetes pod events to a centralized logging platform for retrospective analysis.
How to Mitigate CVE-2026-55514
Immediate Actions Required
- Upgrade vLLM to version 0.24.0 or later on all inference hosts serving M-RoPE models.
- Audit which API tokens can reach /v1/completions and revoke credentials that do not require completion access.
- Restrict network exposure of the vLLM API to trusted internal callers until patched.
Patch Information
The fix is delivered in vLLM v0.24.0 via PR #45252 and commit 470229c. Full details are in the GHSA-33cg-gxv8-3p8g security advisory. The patch removes the assertion that required prompt_token_ids in the M-RoPE initialization path.
Workarounds
- Block or reject /v1/completions requests containing a prompt_embeds field at an API gateway or Web Application Firewall (WAF) until the upgrade is applied.
- Serve non-M-RoPE models on affected vLLM versions where operationally acceptable.
- Run vLLM behind a supervisor that rate-limits crashes and quarantines the source client identity after repeated worker failures.
# Upgrade vLLM to the patched release
pip install --upgrade "vllm>=0.24.0"
# Verify the installed version
python -c "import vllm; print(vllm.__version__)"
# Example NGINX gateway rule to drop prompt_embeds payloads pre-patch
# location /v1/completions {
# if ($request_body ~* "\"prompt_embeds\"") { return 400; }
# proxy_pass http://vllm_upstream;
# }
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

