CVE-2026-54233: vLLM Audio Transcription Denial of Service (CVSS 6.5)
vLLM, an open-source inference engine for large language models, contains a denial-of-service vulnerability in its audio transcription endpoint. The flaw allows an authenticated user to upload a heavily compressed audio file that expands dramatically upon decoding, consuming excessive server memory and crashing the service. A 25 MB compressed OPUS file can balloon to approximately 14.9 GB of uncompressed audio data, overwhelming the system. This affects vLLM versions prior to 0.23.1rc0.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 6.5 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
- Weaknesses (CWE)
- CWE-409
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-22 / 2026-06-24
NVD description (verbatim)
vLLM is an inference and serving engine for large language models (LLMs). Prior to 0.23.1rc0, vLLM's /v1/audio/transcriptions endpoint limits compressed upload size but not decoded PCM output. A 25MB OPUS file expands to ~14.9GB of float32 PCM at decode time. This vulnerability is fixed in 0.23.1rc0.
2 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
CVE-2026-54233 exploits insufficient resource validation in vLLM's /v1/audio/transcriptions endpoint. While the endpoint enforces size limits on the compressed upload payload, it lacks corresponding limits on the decoded PCM output. An attacker with valid credentials can craft a request containing a highly compressed OPUS audio file. Upon server-side decompression, the output expands far beyond the original upload size constraint, resulting in uncontrolled memory allocation. This memory exhaustion triggers an availability impact, effectively denying service to legitimate requests. The vulnerability is rooted in CWE-409 (Improper Restriction of Rendered UI Layers or Frames), though the root cause is resource exhaustion rather than UI-specific issues.
Business impact
Organizations deploying vLLM for audio transcription services face potential service disruption. An authenticated attacker can trigger denial-of-service conditions by repeatedly uploading compressed files, making the transcription endpoint unavailable to legitimate users. This is particularly concerning for production deployments relying on vLLM for customer-facing or mission-critical speech-to-text functionality. Recovery requires manual intervention or service restart, leading to downtime and operational disruption. While authentication is required, compromised or malicious internal accounts, or integration scenarios with untrusted clients, pose a credible threat.
Affected systems
vLLM versions prior to 0.23.1rc0 are vulnerable. Organizations should audit their vLLM deployment versions immediately. The vulnerability is specific to the /v1/audio/transcriptions endpoint; deployments not exposing this endpoint or using vLLM purely for text-based LLM inference may have reduced exposure, though this should be verified against your specific configuration.
Exploitability
Exploitation requires valid authentication credentials to access the endpoint, which limits casual or opportunistic attacks. However, the attack is trivial to execute once authenticated—no specialized tools or complex manipulation are required, only the ability to craft a POST request with a compressed audio file. The attack is deterministic and reliable; a 25 MB OPUS file will consistently trigger the vulnerability on vulnerable versions. In environments where API access is broadly granted or where service accounts have weak credential management, the barrier to exploitation is minimal.
Remediation
Upgrade vLLM to version 0.23.1rc0 or later. This release includes fixes that enforce resource limits on decoded output, preventing uncontrolled memory expansion. Review the vLLM release notes for that version to confirm the fix addresses this specific endpoint. Additionally, implement network-level and application-level rate limiting on the /v1/audio/transcriptions endpoint to mitigate potential abuse, and restrict access to this endpoint to trusted clients only using authentication and authorization controls.
Patch guidance
Apply the upgrade to vLLM 0.23.1rc0 or a later stable release. Verify compatibility with your current Python environment and any dependent services before upgrading production instances. Test the patched version against your audio transcription workloads to ensure no regressions. If you are currently on a version significantly older than 0.23.1, check the vLLM release notes for any breaking changes or additional security fixes included in intervening releases. Plan the upgrade during a maintenance window to avoid service disruption.
Detection guidance
Monitor server memory usage patterns on instances running the /v1/audio/transcriptions endpoint. Sudden spikes in memory consumption following audio upload requests may indicate exploitation attempts. Log and alert on repeated failed allocations or out-of-memory errors originating from the audio transcription service. Review authentication logs for access to this endpoint, particularly from unexpected or suspicious accounts. Network IDS/IPS rules can be configured to detect unusually large memory allocations or process crashes on vLLM services following transcription requests, though signature-based detection is limited without application-level visibility.
Why prioritize this
Although the CVSS score is moderate (6.5/MEDIUM), the vulnerability warrants prompt attention due to the ease of exploitation and guaranteed availability impact. Any authenticated user can reliably crash the service with a single request. For organizations heavily dependent on vLLM for audio transcription or running vLLM in a multi-tenant or semi-trusted environment, this represents a credible and practical threat. The fix is mature (released in 0.23.1rc0) and does not appear to be experimental, making remediation straightforward. Prioritize patching over defensive measures alone.
Risk score, explained
The CVSS v3.1 score of 6.5 reflects the vulnerability's profile: network-accessible endpoint, low attack complexity, requirement for low-privileged authentication, and guaranteed availability impact. The severity is MEDIUM rather than HIGH because confidentiality and integrity are unaffected; the impact is strictly denial of service. The requirement for valid credentials prevents unauthenticated exploitation, reducing the overall score. However, in real-world deployments where credentials are shared, weak, or overly permissive, the practical risk may exceed the CVSS rating.
Frequently asked questions
Can an unauthenticated attacker exploit this vulnerability?
No. The /v1/audio/transcriptions endpoint requires valid authentication credentials. However, if your vLLM instance is exposed to untrusted networks with weak credential controls, or if internal user accounts are compromised, the authentication requirement provides limited protection.
Does this vulnerability affect vLLM text-based inference models?
No. The vulnerability is specific to the audio transcription endpoint (/v1/audio/transcriptions). Standard LLM text inference endpoints are not affected. If your vLLM deployment does not expose or use the audio transcription feature, this vulnerability does not apply.
What happens if we apply rate limiting instead of upgrading?
Rate limiting on the endpoint can reduce the frequency of successful attacks but does not eliminate the vulnerability. A single malicious request can still crash the service. Rate limiting is a useful defense-in-depth measure but should be combined with upgrading to 0.23.1rc0 or later, not used as a substitute for patching.
Is there a workaround if we cannot upgrade immediately?
Temporarily disable or restrict access to the /v1/audio/transcriptions endpoint using network or application-level access controls. Route traffic through a proxy that enforces strict memory limits on responses, or implement queue-based rate limiting that prevents concurrent high-memory-consumption requests. These are interim measures; upgrade as soon as operationally feasible.
This analysis is based on the CVE record and vendor advisory published as of June 2026. vLLM is an open-source project; deployments may vary. Organizations should verify patch applicability and compatibility with their specific environment before applying updates. SEC.co does not provide exploitation code or detailed attack walkthroughs. This vulnerability does not yet appear on CISA's Known Exploited Vulnerabilities (KEV) catalog; however, the low barrier to exploitation means widespread awareness may accelerate practical attacks. For the latest guidance, consult the official vLLM security advisory and release notes. Source: NVD (public-domain), retrieved 2026-07-28. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-10725HIGHProtocol::HTTP2 HTTP/2 Bomb Memory Exhaustion Vulnerability
- CVE-2026-44697HIGHKlever-Go Remote Denial-of-Service via Decompression Bomb
- CVE-2026-47774HIGHEnvoy HTTP/2 Memory Exhaustion Denial of Service
- CVE-2026-48502HIGHMessagePack for C# Stack Overflow in Timestamp Parsing
- CVE-2026-48510HIGHMessagePack for C# LZ4 Decompression Memory Exhaustion DoS
- CVE-2026-49975HIGHApache HTTP Server Memory Allocation DoS Vulnerability (2.4.17–2.4.67)
- CVE-2026-54278HIGHAIOHTTP Zip Bomb DoS Vulnerability (3.14.1 Fix)
- CVE-2026-54314HIGHn8n Compression Node Decompression Bomb DoS Vulnerability