CVE-2026-55514: 
NixOS vulnerability analysis and mitigation

CVE-2026-55514 is a Denial of Service vulnerability in vLLM, a library for LLM inference and serving, caused by a reachable assertion failure in the EngineCore component. When a /v1/completions request containing a pure prompt_embeds payload (with prompt=None) is sent to a model using Multimodal Rotary Position Embedding (M-RoPE), the _init_mrope_positions method in GPUModelRunner triggers an AssertionError, fatally crashing the entire server application. The vulnerability affects vLLM versions 0.12.0 through 0.23.x (before 0.24.0) and was disclosed on July 6, 2026. It carries a CVSS v3.1 score of 6.5 (Medium) and a CVSS v4.0 score of 7.1 (High) (GitHub Advisory, Red Hat).

The root cause is a reachable assertion (CWE-617) introduced in commit 56669c1, where a type-narrowing assert req_state.prompt_token_ids is not None was added to the _init_mrope_positions method in vllm/v1/worker/gpu_model_runner.py. This assertion is intended to prevent mypy type errors but is not always valid: a /v1/completions request that specifies prompt=None and prompt_embeds=<data> creates a CachedRequestState where prompt_token_ids is None, directly triggering the assertion. The attack requires the server to be configured with --enable-prompt-embeds and loaded with an M-RoPE-supported model (e.g., Qwen2-VL), and the attacker must have low-privilege authenticated access to the /v1/completions endpoint. The fix (PR #45252) replaces the fatal assertion with conditional logic that uses dummy token IDs derived from the embedding sequence length when prompt_token_ids is None (GitHub Advisory, Fix Commit).

Successful exploitation causes the vLLM EngineCore process to crash with an unhandled AssertionError, which propagates to the API server and results in complete service unavailability for all connected clients. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Because a single malicious request is sufficient to bring down the entire server, any authorized API user can act as a denial-of-service vector, making this particularly impactful in multi-tenant or shared inference deployments (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation as of the disclosure date. The EPSS score is approximately 0.33%, reflecting low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the advisory notes that exploitation is "extremely easy" for any authorized user — essentially copying the official prompt_embeds online mode documentation examples with a null prompt field is sufficient to trigger the crash (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a vLLM server instance (versions 0.12.0–0.23.x) that is configured with --enable-prompt-embeds and is serving an M-RoPE-compatible model (e.g., Qwen2-VL, Qwen2.5-VL).
2. Obtain credentials: Acquire any valid API key or authentication token that grants access to the /v1/completions endpoint (low-privilege access is sufficient).
3. Craft the malicious request: Construct a POST request to /v1/completions with prompt set to null and prompt_embeds set to a valid embedding tensor payload, for example:

{
  "model": "<m-rope-model-name>",
  "prompt": null,
  "prompt_embeds": [[0.1, 0.2, ...]]
}

4. Send the request: Submit the crafted request to the target server. The _init_mrope_positions method will encounter prompt_token_ids=None and trigger the fatal AssertionError.
5. Server crash: The EngineCore process crashes with AssertionError: M-RoPE requires prompt_token_ids to be available., propagating an EngineDeadError to the API server and shutting down the entire vLLM application (GitHub Advisory, Fix Commit).

• Logs: EngineCore error log entries containing AssertionError: M-RoPE requires prompt_token_ids to be available. in gpu_model_runner.py at line ~1582; API server logs showing EngineDeadError: EngineCore encountered an issue in async_llm.py; log pattern: (EngineCore pid=<N>) ERROR ... AssertionError: M-RoPE requires prompt_token_ids to be available.
• Logs: API server entries: (APIServer pid=<N>) ERROR ... vllm.v1.engine.exceptions.EngineDeadError: EngineCore encountered an issue.
• Network: Unexpected POST requests to /v1/completions with a JSON body containing "prompt": null and a prompt_embeds field from an authenticated client.
• Process: Sudden termination of the vLLM EngineCore worker process followed by the API server process exiting or becoming unresponsive (GitHub Advisory).

The primary remediation is to upgrade vLLM to version 0.24.0 or later, which replaces the fatal assertion with safe conditional logic (vLLM v0.24.0 Release, Fix Commit). If immediate patching is not feasible, restrict access to the /v1/completions endpoint to trusted users only, and consider disabling --enable-prompt-embeds if the feature is not required. Additionally, deploying a reverse proxy or API gateway with request validation to reject /v1/completions requests where prompt is null can serve as a temporary mitigation (GitHub Advisory).

The vulnerability was reported by security researcher qthequartermasterman and coordinated by jperezdealgaba, who is credited with a broader batch of security hardening contributions included in the vLLM v0.24.0 release. The v0.24.0 release notes explicitly highlight this fix as part of a "coordinated security-hardening batch" addressing multiple denial-of-service vectors. Red Hat tracked the issue via Bugzilla (Bug 2497504) and assigned it medium severity (vLLM v0.24.0 Release, Red Hat Bugzilla).