vLLM CVE-2026-55646

Exploitation requires network access to the vLLM API server and valid API credentials granting at least low-privilege access (confirmed by CVSS PR:L). The vulnerable code paths are exclusively the /v1/audio/transcriptions and /v1/audio/translations endpoints - deployments that do not expose audio transcription routes, or that have disabled speech-to-text model support, are not affected. Only versions 0.22.0 through 0.23.0 are vulnerable; the flaw was introduced with these audio endpoints and does not affect text-only inference routes. Exploitation is limited to availability impact - no confidentiality or integrity compromise is possible through this vector. Authentication (PR:L) is the primary barrier: environments with strict API key issuance and revocation policies significantly reduce exposure compared to shared or broadly distributed credentials.

The CVSS 3.1 score of 6.5 (Medium) accurately reflects the threat profile: network-reachable (AV:N), trivially low complexity (AC:L), but gated behind low-privilege authentication (PR:L), with impact limited entirely to availability (A:H, C:N, I:N). The PR:L requirement is the primary risk-limiting factor - this is not unauthenticated exploitation. In environments where vLLM API keys are broadly issued (shared inference clusters, multi-tenant inference-as-a-service platforms, internal developer tooling without strict API access controls), the effective barrier is low and the impact - crashing or memory-starving the inference process - is operationally significant. EPSS data was not provided in the input and cannot be assessed. There is no CISA KEV listing and no public exploit code identified, placing this in a lower urgency tier for most deployments. However, organizations running vLLM 0.22.x-0.23.x with exposed audio endpoints and broad API access should treat this as a priority patch given the trivial exploitation mechanics once credentials are held.

An attacker with low-privilege vLLM API credentials (e.g., a shared API key from an internal inference platform) sends a multipart POST to /v1/audio/transcriptions containing a multi-gigabyte file payload. Before any size validation runs, vLLM's request handler calls request.file.read(), allocating gigabytes of heap memory in the inference server process. Depending on the deployment's memory limits, this either triggers an OOM-kill terminating all active inference workloads or causes severe memory pressure degrading latency for all concurrent users.