vLLM Timing Attack on API Key Validation - CVE-2025-59425 Analysis

TL;DR

• CVE-2025-59425 is a CWE-385 timing attack in vLLM's built-in API key validation, allowing remote authentication bypass.
• CVSS 7.5 (High) - network-accessible, no privileges or user interaction required.
• Affects all vllm-project/vllm releases before 0.11.0rc2.
• No confirmed in-the-wild exploitation at the time of writing; not listed in the CISA Known Exploited Vulnerabilities catalog.
• Fix: upgrade to vLLM 0.11.0rc2 or later; apply network-level access controls as a short-term workaround.

---

What is CVE-2025-59425?

CVE-2025-59425 is a timing attack vulnerability (CWE-385) in the API key validation logic of vLLM, the open-source inference and serving engine for large language models. The flaw allows a remote, unauthenticated attacker to statistically infer the correct API key by measuring how long the server takes to reject each guess, ultimately bypassing authentication entirely.

The root cause is a non-constant-time string comparison in vLLM's OpenAI-compatible API server. String comparisons in most languages short-circuit or take variable time depending on how many leading characters match. An attacker who can send many requests and measure response latencies can determine, character by character, when a guess matches the next position in the real key. The GitHub security advisory GHSA-wr9h-g72x-mwhm confirmed the issue and the fix in version 0.11.0rc2.

---

Who is affected?

• vllm-project/vllm - all versions before 0.11.0rc2.
• Any deployment that relies on vLLM's built-in --api-key validation to protect the HTTP endpoint.
• Self-hosted vLLM instances exposed directly to untrusted networks (internet-facing or shared internal networks).
• Cloud or on-premises LLM serving pipelines where vLLM handles authentication without an upstream proxy.

---

How severe is it?

The CVSS 3.1 base score is 7.5 (High) with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N.

Breaking that down:

• AV:N - exploitable over the network with no physical access needed.
• AC:L - low attack complexity; the technique is well-documented and requires only HTTP requests.
• PR:N / UI:N - no privileges and no victim interaction required.
• C:H - full confidentiality impact; a successful attacker gains authenticated access to the LLM inference API.
• I:N / A:N - the vulnerability itself does not directly modify data or crash the service, though an authenticated attacker could then misuse the API.

Real-world impact is significant for any organization using vLLM to serve sensitive or proprietary models. An attacker who recovers the API key gains the ability to query the model, potentially exfiltrating prompt context, fine-tuning data artifacts, or incurring large compute costs. The attack does require many repeated requests, meaning high-volume traffic from a single source is a detectable signal.

---

Is it being exploited?

No public in-the-wild exploitation is confirmed at the time of writing. CVE-2025-59425 does not appear in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack technique is generic and well-understood - timing attacks against naive string comparisons are a standard tool in authentication bypass research. The low attack complexity rating means a motivated attacker with network access does not need specialized skills or tooling.

---

How to fix and mitigate it

1. Upgrade vLLM to version 0.11.0rc2 or later. The official release replaces the vulnerable comparison with a constant-time equivalent, which eliminates the timing side-channel. This is the only complete fix.

# Upgrade via pip
pip install --upgrade "vllm>=0.11.0rc2"

# Verify installed version
python -c "import vllm; print(vllm.__version__)"

2. Place vLLM behind an authenticating reverse proxy (nginx, Envoy, AWS API Gateway, etc.) as an interim control if upgrading immediately is not possible. Move authentication enforcement upstream so vLLM's own key validation is never reached by untrusted traffic.

3. Restrict network access to vLLM's HTTP port using firewall rules or security groups. Allow only known, trusted IP ranges.

# Example: restrict access with iptables (Linux)
iptables -A INPUT -p tcp --dport 8000 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8000 -j DROP

4. Rotate your API key after upgrading. If the service was network-accessible before patching, treat the existing key as potentially compromised.

5. Review the patched code path at vllm/entrypoints/openai/api_server.py lines 1270-1274 and the fixing commit to confirm the constant-time comparison is in place in your build.

---

How to detect exposure

• Check your vLLM version before anything else. Any version string below 0.11.0rc2 on a deployment using --api-key is vulnerable.
• Inspect HTTP access logs for high volumes of requests returning 401 or 403 from a single IP or small IP range. A timing attack sends hundreds to thousands of probes - this pattern stands out against normal traffic.
• Look for incremental key guessing patterns - requests with API keys that share increasingly long common prefixes are a signature of this attack.
• Enable rate limiting on the vLLM endpoint or the upstream proxy; a sudden spike in authentication failures is a useful alert threshold.
• Use a SIEM or log aggregation tool to alert on authentication failure rates exceeding a defined baseline for your deployment.

---

Frequently asked questions

Can an attacker exploit this without any valid credentials?

Yes. The timing attack requires no prior knowledge of the API key. By sending many requests and measuring response times statistically, an attacker can reconstruct the correct key one character at a time, eventually gaining full authentication bypass without ever holding a legitimate credential.

Does this affect all vLLM deployments?

Only deployments that rely on vLLM's built-in API key validation are affected. If you front your vLLM instance with an external authentication proxy or gateway that handles key checking independently, the vulnerable code path in vLLM itself is not the enforcement point.

How many requests does a timing attack typically require?

Timing attacks against string comparisons can require thousands to tens of thousands of requests to gather statistically reliable timing signals per character. The exact count depends on network jitter, server load, and key length, but the attack is entirely feasible against a remotely accessible endpoint.

Is there a workaround if I cannot upgrade immediately?

Yes. Place vLLM behind a reverse proxy or API gateway that enforces authentication before requests reach vLLM. Alternatively, restrict network access to trusted IP ranges only. These mitigations reduce attack surface but do not fix the underlying flaw; upgrading to 0.11.0rc2 or later is the definitive fix.