vLLM versions prior to 0.29.0 have a flaw in media handling where the server fetches and fully materializes remote or inline media before applying documented media size and count limits. This occurs across four ingress paths: the shared media-acquisition layer (HTTPConnection.get_bytes()/async_get_bytes()), the chat completions audio_url/base64 path, the batch speech runner, and the Rust frontend POST /tokenize route. Because limits are enforced only after full data retrieval or sometimes not at all, a remote attacker can cause the server to allocate memory and consume outbound bandwidth proportional to attacker-controlled media size or count. This results in denial of service through pre-inference memory and bandwidth exhaustion. The chat and batch interfaces require API keys if configured, but the Rust frontend /tokenize route is unauthenticated by design. There is no impact on code execution or data confidentiality.

An attacker can cause denial of service by exhausting memory and bandwidth resources on the vllm server or batch-runner process before media size limits are enforced or the request is rejected. This can degrade or disrupt service availability. There is no impact on code execution or data disclosure.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, restrict access to the unauthenticated Rust frontend /tokenize route if possible and monitor for abnormal resource usage. The chat and batch surfaces require API keys when configured, which limits exposure. No code execution or data disclosure risk reduces urgency but resource exhaustion risk remains.