vLLM CVE-2025-59425

Exploitable ONLY against deployments that enable vLLM's built-in API key authentication (the AuthenticationMiddleware / --api-key path guarding /v1 routes) in versions before 0.11.0rc2; deployments with no auth, or those fronted by an external API gateway/reverse proxy that handles authentication, are not affected by this specific flaw. No user interaction or prior authentication is required (PR:N, UI:N), but practical exploitation is LIMITED by the need for a very large number of timed requests and by network latency/jitter, which can swamp the per-character timing signal - making remote exploitation probabilistic and slow rather than deterministic. The attacker must also have network reachability to the vLLM API endpoint.

Signals are moderate and largely consistent. CVSS 3.1 (7.5, AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:N) frames this as a network-reachable, unauthenticated confidentiality issue - the recovered API key grants full access to the LLM inference endpoint. However, the AC:L rating understates reality: a remote timing side-channel against a SHA-free string comparison requires large volumes of requests and is heavily degraded by network jitter, so practical exploitation is harder than AC:L implies (I assess AC:H). EPSS is low (0.57%, 46th percentile), and the vulnerability is NOT in CISA KEV, indicating no confirmed active exploitation. POC/exploit code is reported publicly available and the GitHub advisory (GHSA-wr9h-g72x-mwhm) plus the fix commit confirm the root cause, but publicly available exploit code is a distinct signal from active exploitation and should not be conflated with it. Net: this is a legitimate authentication-weakness to patch, but it is a high-CVSS / lower-real-world-risk item - exploitation is non-trivial, probabilistic, and only affects deployments that actually rely on vLLM's built-in API key auth rather than an external gateway. Note CWE-385 (Covert Timing Channel) matches the mechanism and corroborates the timing-attack framing.

An attacker with network access to a vLLM server that uses its built-in --api-key authentication issues a large, automated series of Bearer-token requests, measuring response-time differences to recover the key one character at a time (the vulnerable byte-by-byte comparison takes longer as more leading characters match). Having reconstructed a valid key, the attacker authenticates and freely abuses the LLM inference API. Publicly available exploit code is reported for this technique, though success depends on low network jitter and many samples.