CVE-2026-114052: vLLM MOSS-Audio Model Serving DOS Vulnerability

CVE-2026-114052 Overview

CVE-2026-114052 is a memory exhaustion vulnerability affecting vLLM versions after 0.24.0 and before 0.31.0. The flaw resides in the MOSS-Audio model serving path, which caches a processor instance for every distinct request-controlled mm_processor_kwargs value in an unbounded dictionary. Unauthenticated attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses the --api-key enforcement. Repeated requests exhaust host memory and crash the API process. The weakness is classified under CWE-770 (Allocation of Resources Without Limits or Throttling).

Critical Impact
Unauthenticated remote attackers can crash vLLM inference servers through memory exhaustion, taking the API process offline and disrupting dependent AI workloads.

Affected Products

vLLM versions after 0.24.0 and before 0.31.0
Deployments serving the MOSS-Audio model
vLLM API servers exposing the /tokenize endpoint

Discovery Timeline

2026-10-21 - CVE-2026-114052 published to NVD
2026-10-22 - Last updated in NVD database

Technical Details for CVE-2026-114052

Vulnerability Analysis

The vulnerability resides in vLLM's MOSS-Audio multimodal serving code. When a request arrives, vLLM constructs a processor instance keyed by the values supplied in mm_processor_kwargs. Those processor instances are retained in an in-memory dictionary without any eviction or size cap. Because the mel_config field is attacker-controlled, each unique value creates a new cache entry and allocates memory for the associated processor state.

The /tokenize endpoint is reachable without authentication even when the operator starts vLLM with --api-key. Attackers can therefore iterate through many distinct mel_config payloads, or send oversized configurations, to force unbounded growth of the processor cache. Memory consumption continues until the host runs out of RAM and the vLLM API process terminates. The flaw does not affect confidentiality or integrity, but it directly impacts availability for any application that depends on the inference endpoint.

Root Cause

The root cause is missing resource throttling in the processor caching logic. The cache uses request-controlled values as dictionary keys with no maximum size, no least-recently-used eviction, and no input validation on mel_config structure or dimensions. This matches the pattern described by CWE-770.

Attack Vector

An unauthenticated remote attacker sends crafted HTTP POST requests to the /tokenize endpoint of a vLLM server configured to serve MOSS-Audio. Each request includes a unique or oversized mel_config inside mm_processor_kwargs. Scripted iteration drives memory usage upward until the process is killed by the operating system or crashes outright.

The vulnerability mechanism is described in prose rather than code; refer to the GitHub Security Advisory GHSA-823j-m4cj-hmjf and the VulnCheck Advisory on Memory Exhaustion for implementation specifics.

Detection Methods for CVE-2026-114052

Indicators of Compromise

Sustained growth of resident set size (RSS) for the vLLM process without a corresponding increase in legitimate traffic volume.
High request rates to /tokenize originating from a single source or small set of IP addresses.
Repeated POST bodies containing varying mm_processor_kwargs.mel_config values.
vLLM API process restarts or out-of-memory (OOM) killer entries in dmesg or systemd journal logs.

Detection Strategies

Log and inspect request bodies to /tokenize for unique mel_config values per source IP within short time windows.
Correlate container or host memory metrics with request logs to identify monotonically increasing memory consumption tied to tokenize traffic.
Alert on anonymous (no API key or bearer token) requests to /tokenize when authentication is otherwise required on the deployment.

Monitoring Recommendations

Export vLLM process memory metrics to Prometheus or an equivalent monitoring stack and set thresholds for abnormal growth.
Enable WAF or reverse proxy logging in front of vLLM to retain full request bodies for forensic review.
Track OOM kill events on hosts running vLLM and route them to the SOC for triage.

How to Mitigate CVE-2026-114052

Immediate Actions Required

Upgrade vLLM to version 0.31.0 or later, which addresses the unbounded processor cache.
Restrict network exposure of the vLLM API server to trusted clients using firewall rules or private networking.
Place an authenticating reverse proxy in front of vLLM so the /tokenize endpoint cannot be reached anonymously.
Audit recent access logs for high-volume or anomalous requests to /tokenize.

Patch Information

The maintainers resolved the issue in vLLM 0.31.0. Operators running any version after 0.24.0 and before 0.31.0 that serves MOSS-Audio should upgrade immediately. Patch details are published in the GitHub Security Advisory GHSA-823j-m4cj-hmjf.

Workarounds

Disable MOSS-Audio model serving until the upgrade is applied.
Enforce authentication on /tokenize at the proxy layer, since --api-key alone does not protect this endpoint.
Apply rate limiting on /tokenize by source IP and reject requests containing unexpected mm_processor_kwargs fields.
Run vLLM under a memory cgroup with a hard limit so a single process crash does not destabilize the host.

bash

# Configuration example: upgrade and restrict exposure
pip install --upgrade "vllm>=0.31.0"

# Example NGINX snippet: require auth and rate-limit /tokenize
# limit_req_zone $binary_remote_addr zone=tokenize:10m rate=5r/s;
# location = /tokenize {
#     auth_request /_auth;
#     limit_req zone=tokenize burst=10 nodelay;
#     proxy_pass http://vllm_upstream;
# }