# vLLM Unbounded Video Frame Flood (Multimodal Resource Exhaustion)

- **Severity:** Medium
- **Signature ID:** `6b1f0a9c-42d7-4c3e-9a58-77f0d1c8e214`
- **MITRE ATLAS:** AML.T0050 (Command and Scripting Interpreter)
- **OWASP:** ASI07 (Unsafe Autonomous Code Execution)

## Summary

A local process or AI agent can send a specially crafted video request to a vLLM server that packs in far more video frames than the server is designed to handle. Because one code path skips the normal frame-count limit, the server tries to decode all the frames into memory at once, which can exhaust RAM and crash the process.

## How the attack works

An attacker or misbehaving agent builds a multimodal inference request containing a data URI with a video media type. Instead of a normal video file, the payload is a comma-separated list of thousands of base64-encoded JPEG frames. vLLM's video-loading code splits on commas and decodes every frame into memory without checking against the frame-count limit it enforces elsewhere. Decoding thousands of frames into numpy arrays at once can exhaust available memory and crash the server, denying service to other users.

## Why it matters

A single crafted request can take down a shared inference server, disrupting every other user or agent depending on it, with no need for authentication beyond normal API access.

## What you can do

- Set a hard limit on request body size and reject video data URIs with an excessive number of comma-separated segments before they reach the model server.
- Monitor outbound requests from agents for data URIs whose decoded frame count exceeds your configured sampler limit (default 32 in vLLM).
- Run vLLM inference behind resource limits (memory cgroups, container quotas) so a single request cannot exhaust host memory.
- Patch or upgrade vLLM once a fix for unbounded frame parsing is available, and verify the fix by replaying oversized payloads in a test environment.

## Known benign look-alikes

- Video-understanding agents that legitimately sample more than 64 frames from a long clip and inline them as a video/jpeg data URI. Confirm the destination host is an approved inference endpoint and that the frame count matches the configured sampler.
- Benchmark, load-test or capacity-planning harnesses that deliberately push oversized multimodal payloads at a self-hosted vLLM instance.
- Security validation of the fix for this exact issue (regression tests that replay the malicious payload against a patched server).
- A client that inlines an animated sequence converted frame-by-frame to JPEG rather than uploading a container file and passing a URL.

## References

- https://github.com/vllm-project/vllm
- https://attack.mitre.org/techniques/T1499/

---
Source: https://www.netzilo.com/threats/vllm-video-frame-flood-dos