CVE-2026-55646: vLLM audio upload OOMs process

Q: Is CVE-2026-55646 actively exploited?

No confirmed active exploitation of CVE-2026-55646 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-55646?

1) Upgrade to vLLM 0.24.0 or later, where the size check is enforced before the file is read into memory. 2) Until patched, enforce a hard body-size limit at the reverse proxy or API gateway in front of vLLM (e.g., Nginx client_max_body_size, Envoy max_request_bytes, or cloud LB request size limits) set at or below VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (default 25MB). 3) Apply per-tenant/per-key rate limiting on the audio endpoints to blunt repeated-upload abuse. 4) Monitor process memory and OOM-kill events on vLLM audio-serving nodes; alert on sudden RSS spikes correlated with /v1/audio/transcriptions or /v1/audio/translations traffic. 5) If audio endpoints aren't in active use, disable or firewall them off entirely to shrink the attack surface.

Q: What systems are affected by CVE-2026-55646?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference gateways, multimodal/speech-to-text pipelines.

Q: What is the CVSS score for CVE-2026-55646?

CVE-2026-55646 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.29%.

CISO Take

vLLM's speech-to-text endpoints (/v1/audio/transcriptions and /v1/audio/translations) read the entire uploaded file into memory before enforcing the documented 25MB VLLM_MAX_AUDIO_CLIP_FILESIZE_MB limit, so an oversized multipart upload forces memory allocation proportional to file size before the request is ever rejected. Any authenticated caller with low privileges can trigger this over the network with no user interaction and low attack complexity, and with 129 downstream dependents on this package, any product embedding vLLM's audio endpoints inherits the exposure. There is no CISA KEV listing, no public exploit, and no scanner template today, and EPSS sits low (0.29%), so this reads as a reliability/availability risk rather than an actively weaponized one — but it is trivial to trigger and can crash or destabilize an inference node with a handful of oversized requests. Patch to vLLM 0.24.0, and until then place a reverse-proxy body-size cap (e.g., Nginx client_max_body_size or a WAF rule) in front of any deployment exposing the audio transcription/translation routes, since the internal limit is enforced too late to help.

Sources: NVD GitHub Advisory EPSS ATLAS

What is the risk?

Medium severity (CVSS 6.5, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) — this is a pure availability issue with no confidentiality or integrity impact. Exploitability is high (network-reachable, low complexity, no user interaction), but requires low privileges (a valid API credential), which limits it to insiders or credentialed API abusers rather than fully anonymous internet attackers. No active exploitation signals exist (not in CISA KEV, no public PoC, no Nuclei template), and EPSS is very low, so near-term mass exploitation is unlikely. The real risk driver is operational: any multi-tenant or shared vLLM deployment exposing audio endpoints can be knocked over by a single malicious or careless oversized upload, and the package's track record (82 other CVEs, high churn) suggests this class of validation-ordering bug may recur.

How does the attack unfold?

Entry point

A caller with valid low-privilege API access sends a multipart upload to /v1/audio/transcriptions or /v1/audio/translations with a file far exceeding the 25MB configured limit.

AML.T0034.001

Validation-order flaw exploited

vLLM calls request.file.read() and buffers the full file into memory before the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB check runs later in speech-to-text preprocessing.

Resource exhaustion

Memory allocation proportional to the oversized file drives the process toward memory pressure, especially under repeated or concurrent oversized uploads.

AML.T0034.001

Impact

The vLLM process is OOM-killed or destabilized, denying inference service to all models and tenants sharing that instance.

AML.T0029

Entry point

A caller with valid low-privilege API access sends a multipart upload to /v1/audio/transcriptions or /v1/audio/translations with a file far exceeding the 25MB configured limit.

AML.T0034.001

Validation-order flaw exploited

vLLM calls request.file.read() and buffers the full file into memory before the VLLM_MAX_AUDIO_CLIP_FILESIZE_MB check runs later in speech-to-text preprocessing.

Resource exhaustion

Memory allocation proportional to the oversized file drives the process toward memory pressure, especially under repeated or concurrent oversized uploads.

AML.T0034.001

Impact

The vLLM process is OOM-killed or destabilized, denying inference service to all models and tenants sharing that instance.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	>= 0.22.0, < 0.24.0	`0.24.0`
89.7K 128 dependents Pushed today 25% patched ~52d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 22% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I None

A High

What should I do?

1 step

1) Upgrade to vLLM 0.24.0 or later, where the size check is enforced before the file is read into memory. 2) Until patched, enforce a hard body-size limit at the reverse proxy or API gateway in front of vLLM (e.g., Nginx client_max_body_size, Envoy max_request_bytes, or cloud LB request size limits) set at or below VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (default 25MB). 3) Apply per-tenant/per-key rate limiting on the audio endpoints to blunt repeated-upload abuse. 4) Monitor process memory and OOM-kill events on vLLM audio-serving nodes; alert on sudden RSS spikes correlated with /v1/audio/transcriptions or /v1/audio/translations traffic. 5) If audio endpoints aren't in active use, disable or firewall them off entirely to shrink the attack surface.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Inference API AML.T0029 - Denial of AI Service AML.T0034.001 - Resource-Intensive Queries

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.8 - AI system operational management

NIST AI RMF

MEASURE 2.7 - AI system security and resilience

OWASP LLM Top 10

LLM10 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-55646?

vLLM's speech-to-text endpoints (/v1/audio/transcriptions and /v1/audio/translations) read the entire uploaded file into memory before enforcing the documented 25MB VLLM_MAX_AUDIO_CLIP_FILESIZE_MB limit, so an oversized multipart upload forces memory allocation proportional to file size before the request is ever rejected. Any authenticated caller with low privileges can trigger this over the network with no user interaction and low attack complexity, and with 129 downstream dependents on this package, any product embedding vLLM's audio endpoints inherits the exposure. There is no CISA KEV listing, no public exploit, and no scanner template today, and EPSS sits low (0.29%), so this reads as a reliability/availability risk rather than an actively weaponized one — but it is trivial to trigger and can crash or destabilize an inference node with a handful of oversized requests. Patch to vLLM 0.24.0, and until then place a reverse-proxy body-size cap (e.g., Nginx client_max_body_size or a WAF rule) in front of any deployment exposing the audio transcription/translation routes, since the internal limit is enforced too late to help.

Is CVE-2026-55646 actively exploited?

No confirmed active exploitation of CVE-2026-55646 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-55646?

1) Upgrade to vLLM 0.24.0 or later, where the size check is enforced before the file is read into memory. 2) Until patched, enforce a hard body-size limit at the reverse proxy or API gateway in front of vLLM (e.g., Nginx client_max_body_size, Envoy max_request_bytes, or cloud LB request size limits) set at or below VLLM_MAX_AUDIO_CLIP_FILESIZE_MB (default 25MB). 3) Apply per-tenant/per-key rate limiting on the audio endpoints to blunt repeated-upload abuse. 4) Monitor process memory and OOM-kill events on vLLM audio-serving nodes; alert on sudden RSS spikes correlated with /v1/audio/transcriptions or /v1/audio/translations traffic. 5) If audio endpoints aren't in active use, disable or firewall them off entirely to shrink the attack surface.

What systems are affected by CVE-2026-55646?

This vulnerability affects the following AI/ML architecture patterns: model serving, inference gateways, multimodal/speech-to-text pipelines.

What is the CVSS score for CVE-2026-55646?

CVE-2026-55646 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.29%.

What is the AI security impact?

Affected AI Architectures

model servinginference gatewaysmultimodal/speech-to-text pipelines

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0034.001 Resource-Intensive Queries

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.8

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM10

What are the technical details?

Original Advisory

vLLM is an inference and serving engine for large language models. From 0.22.0 to 0.23.0, the /v1/audio/transcriptions and /v1/audio/translations routes call request.file.read() to fully materialize an uploaded audio file into memory before vLLM checks the documented VLLM_MAX_AUDIO_CLIP_FILESIZE_MB compressed upload size limit (default 25 MB) later in the speech-to-text preprocessing step, so an API caller who can reach those routes 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, creating memory pressure or terminating the process depending on deployment resource limits. This issue is fixed in version 0.24.0.

Exploitation Scenario

An attacker or careless internal user holding valid (even low-privilege) API credentials sends a multipart POST to /v1/audio/transcriptions with an audio file far exceeding the 25MB configured limit — e.g., a multi-gigabyte file. vLLM calls request.file.read() and buffers the entire payload into memory before it ever checks VLLM_MAX_AUDIO_CLIP_FILESIZE_MB in the speech-to-text preprocessing step. Repeating this with a few concurrent oversized uploads, or a single sufficiently large file on a memory-constrained instance, drives the vLLM process into memory pressure or triggers an OOM kill, taking inference offline for every model and tenant sharing that node — a low-effort denial-of-service against a production LLM serving stack.

Weaknesses (CWE)

CWE-400 Uncontrolled Resource Consumption Primary CWE-770 Allocation of Resources Without Limits or Throttling Primary CWE-400 Uncontrolled Resource Consumption CWE-400 Uncontrolled Resource Consumption CWE-770 Allocation of Resources Without Limits or Throttling CWE-770 Allocation of Resources Without Limits or Throttling

CWE-400 — Uncontrolled Resource Consumption: The product does not properly control the allocation and maintenance of a limited resource.

[Architecture and Design] Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
[Architecture and Design] Mitigation of resource exhaustion attacks requires that the target system either: The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker. recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.

Source: MITRE CWE corpus.