al-ice.ai

vLLM CVE-2026-55646 — Audio Upload Memory Exhaustion DoS (CVSS 6.5)

AI CVEs by al-ice.ai Editorial
  • vLLM versions 0.22.0 through 0.23.0 contain a memory exhaustion vulnerability in the speech-to-text endpoints (/v1/audio/transcriptions and /v1/audio/translations)
  • The vulnerability occurs because the endpoints call request.file.read() to fully materialize an uploaded audio file into memory before checking the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB)
  • An attacker who can reach these endpoints can submit an oversized multipart upload and cause vLLM to allocate memory proportional to the uploaded file size before the request is rejected as too large
  • This creates memory pressure or terminates the process depending on deployment resource limits, enabling remote denial-of-service attacks
  • CVSS score: 6.5 (MEDIUM), remotely exploitable
  • CWE-400: Uncontrolled Resource Consumption; CWE-770: Allocation of Resources Without Limits or Throttling
  • The vulnerability is a classic "check after use" flaw: the size validation happens too late, after the resource has already been consumed
  • Fixed in vLLM 0.24.0 (released July 2026)
  • This is the second vLLM CVE disclosed in the past week (CVE-2026-55514, a DoS via prompt-embeds with M-RoPE models, was disclosed July 6)

Why it matters

vLLM is one of the most widely deployed LLM inference engines, powering production serving infrastructure for thousands of organizations. The speech-to-text endpoints are commonly exposed to enable multimodal AI applications (voice assistants, transcription services, audio analysis). This vulnerability allows unauthenticated remote attackers to crash vLLM instances with a single oversized upload, making it a high-impact DoS vector. The "check after use" pattern is a recurring issue in file upload handlers — developers validate size limits after reading the file, not before. For AI infrastructure that processes untrusted input (like audio uploads from users), this pattern is particularly dangerous because the attack surface is internet-facing by design.

What to do

  • Update vLLM to 0.24.0 or later immediately
  • If you cannot update immediately, restrict access to the /v1/audio/transcriptions and /v1/audio/translations endpoints using network controls (firewall rules, API gateway rate limiting, authentication)
  • Implement upload size limits at the reverse proxy or load balancer level (before the request reaches vLLM)
  • Monitor vLLM process memory usage and set up alerts for abnormal spikes
  • Review your vLLM deployment for other file upload endpoints that may have similar "check after use" patterns
  • Consider implementing streaming uploads with early termination if the size exceeds your threshold

Sources: