CVE-2026-5497: vLLM Out-of-Memory DoS Vulnerability in Video Frame Processing

Technical summary

The vulnerability exists in the `VideoMediaIO.load_base64()` method used to handle video/jpeg media in data URLs. The method splits incoming base64-encoded data on comma delimiters to extract individual JPEG frames, then decodes each frame into memory without validating or limiting the frame count. An attacker can construct a single API call to the OpenAI-compatible chat completions endpoint containing a malicious data URL with thousands of comma-separated base64-encoded JPEG frames. The server will attempt to decode every frame, causing unbounded memory allocation that leads to out-of-memory conditions and process termination. This attack vector is reachable without authentication, making it accessible to any network-adjacent threat actor.

Business impact

An attacker exploiting this vulnerability can render a vLLM deployment unavailable by sending a single malicious request. This interrupts inference workloads, breaks dependent applications (chatbots, content moderation systems, summarization services), and forces manual restart of services. For production environments serving multiple users or applications, repeated attacks can create a denial-of-service condition that prevents legitimate use. Organizations relying on vLLM for revenue-generating or mission-critical AI services face operational downtime and potential SLA violations. The attack requires no sophisticated tooling or credentials, lowering the barrier for exploitation.

Affected systems

vLLM versions 0.8.0 through the current version are affected. The vulnerability is only triggered when processing requests that include video/jpeg data in base64-encoded format via the OpenAI-compatible API. Deployments that do not expose the chat completions endpoint or do not accept multimodal (vision) inputs are not impacted. Self-hosted instances, managed SaaS offerings, and integrated vLLM deployments within other systems are all potentially vulnerable if running affected versions and accepting video input.

Exploitability

Exploitability is very high. The attack requires only network access to the vLLM inference endpoint—no authentication, no special privileges, and no user interaction. An attacker can craft the malicious request using standard HTTP libraries in any programming language. The payload is straightforward: a single API call containing a data URL with many comma-separated JPEG frames. The vulnerability does not require bypassing any additional controls, parsing logic, or application-level authentication. This makes it suitable for automated scanning and mass exploitation campaigns targeting exposed vLLM instances on public networks or accessible cloud deployments.

Remediation

Upgrade vLLM to a patched version that enforces frame count limits in the `VideoMediaIO.load_base64()` method. Verify the patched version against the official vLLM release notes and security advisories. In the interim, implement network-level mitigations: restrict access to the OpenAI-compatible API endpoint to trusted sources using firewall rules or API gateway authentication; disable video/multimodal processing if not required; implement request size limits and rate limiting on the inference endpoint to slow or block large payloads; monitor memory usage and set process memory limits (ulimit, cgroups) to trigger graceful shutdown rather than kernel OOM kills.

Patch guidance

Check the official vLLM GitHub repository and release notes for versions addressing CVE-2026-5497. Apply the patched version to all vLLM deployments, including containerized instances. Test the upgrade in a staging environment against your typical multimodal workloads to confirm compatibility before production deployment. If you cannot patch immediately, apply the interim network controls described in the remediation section.

Detection guidance

Monitor for API requests to the chat completions endpoint containing video/jpeg data URLs with unusually high numbers of comma-delimited segments (frame counts in the hundreds or thousands). Alert on sudden spikes in memory usage or out-of-memory process crashes on vLLM servers. Review access logs for requests to `/v1/chat/completions` or similar endpoints with base64-encoded payloads exceeding typical sizes (e.g., >10 MB). Use memory profiling and request inspection to identify malicious frame-loading attempts. Network-based detection can flag requests with repeated comma separators in base64 data, though legitimate multimodal use cases may require tuning thresholds.

Why prioritize this

This vulnerability merits immediate attention due to its high severity (CVSS 7.5), trivial exploitability, and lack of authentication requirements. Any vLLM instance exposed to untrusted networks faces immediate DoS risk. The ease of attack—a single HTTP request—means threat actors can rapidly test and exploit vulnerable instances at scale. Organizations operating vLLM in production should prioritize patching or implementing interim controls. Delayed remediation extends exposure to potential service disruption.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects a network-accessible denial-of-service attack with no authentication requirement and high impact on availability. The vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates the attack is trivial to execute (Low Attack Complexity, no privileges or user interaction), affects only availability (not confidentiality or integrity), and does not require local system access. The score appropriately captures a severe but not critical risk; while the service is disrupted, no data is stolen or corrupted, and attackers cannot gain persistent access or escalate privileges.

Frequently asked questions