CVE-2026-9540

What it actually does

Unauthenticated remote requests against vLLM 0.19.0's OpenAI-compatible serving path can trigger a denial-of-service condition. Per the assigned scoring, only availability is affected (low), with no confidentiality or integrity impact on models, prompts, or responses. The serving process may crash, hang, or become unresponsive, interrupting inference without granting code execution or data access.

Why it matters to the business

Teams using vLLM to back chat, RAG, or other LLM APIs can see those services go offline for users and downstream jobs. The issue is not in CISA KEV and is not tied to ransomware, but a public exploit is reported, the EPSS score rose about 70% over 30 days (0.0043 to 0.0072), and 126 days after publication there is still no accepted upstream fix or listed patched release—so exposed 0.19.0 serving endpoints remain an availability risk until a fix is merged and deployed or access is tightly restricted.

How an attack unfolds

An attacker finds a network-reachable vLLM OpenAI-compatible HTTP API and, without credentials or user interaction, sends crafted requests that abuse unspecified processing on that serving path. The engine then fails or stalls, denying inference to legitimate clients. Because a public exploit is reported, opportunistic scanning and automated abuse are plausible; no named threat actors or ransomware campaigns are associated with this CVE. Details of the request manipulation are not required for defense: treat any unauthenticated, internet-facing vLLM serving port as in-scope until patched or isolated.

How to fix it

No official fixed version is listed; the upstream pull request that addresses this issue is still awaiting acceptance. Until a release that includes that fix is available and deployed, do not expose the OpenAI-compatible serving API to untrusted networks. Require authentication in front of the API, restrict source IPs, place a reverse proxy with strict body-size, timeout, concurrency, and rate limits in front of vLLM, and pin or upgrade off 0.19.0 as soon as an accepted patched build is published. Monitor the vllm-project repository for merge and release notes and treat that upgrade as the durable fix.

How to confirm the fix worked

Inventory running vLLM builds and flag 0.19.0 (and any image/tag derived from it). Confirm whether serving ports are reachable beyond a trusted network and whether an auth-enforcing proxy sits in front. After an upstream fix is accepted and packaged, upgrade and verify the package or container version no longer reports 0.19.0, then exercise normal (benign) chat/completions traffic through the proxy to confirm healthy responses and that previous unrestricted anonymous access is gone. Do not attempt to reproduce the denial-of-service against production.

Typical attack path

1. Discover a reachable vLLM OpenAI-compatible serving endpoint (commonly the HTTP API used as an OpenAI drop-in).
2. Send unauthenticated, crafted remote requests aimed at the serving path.
3. Cause the inference/serving process to hang, crash, or exhaust resources so legitimate completions fail.
4. Optionally repeat or sustain the requests to prolong the outage.

How to detect it

This is an availability issue, so look for impact rather than a unique implant. Review vLLM and reverse-proxy access logs around periods of inference outage for bursts of unauthenticated HTTP requests to OpenAI-compatible routes (/v1/chat/completions, /v1/completions, /v1/embeddings, and related /v1/* paths), followed by 5xx responses, client timeouts, or a drop in successful completions. On hosts, look for unexpected vLLM / Python serving process exits, worker or engine-core deaths, OOM killer activity, and restart loops of the API server. Correlate with orchestrator events (pod restarts, readiness probe failures) and any WAF or API-gateway blocks. There are no named threat actors; hunting should focus on anonymous, high-rate, or malformed traffic to the serving API rather than a specific campaign.

• POST /v1/chat/completions
• POST /v1/completions
• POST /v1/embeddings
• vllm.entrypoints.openai
• WorkerProc.*died
• Engine core.*exited
• NCCL error
• CUDA out of memory
• python -m vllm.entrypoints.openai.api_server

What your security team should do

• Immediately identify all vLLM 0.19.0 OpenAI-compatible serving endpoints and remove them from untrusted or internet-facing networks.
• Put authentication, IP allowlists, and reverse-proxy rate/size/timeout limits in front of any remaining serving API.
• Track the pending upstream pull request and schedule an emergency upgrade as soon as a patched release exists.
• Alert on serving-process crashes, worker deaths, and spikes of 5xx/timeouts on OpenAI-compatible routes.
• Because EPSS is rising and a public exploit is claimed, treat unauthenticated exposure as time-sensitive even though this CVE is not in KEV.