AI Threat Alert
CVE-2026-78684: vLLM: unauthenticated DoS via DeepStream decode bypass
MEDIUMvLLM's multimodal inference path fails to classify DeepStream as a GPU backend and skips pixel-limit checks, letting any unauthenticated caller activate the DeepStream decode pool and submit oversized video that saturates it, degrading service for every other concurrent request on that vLLM instance. This matters because vLLM is a widely-deployed inference engine with 128 downstream dependents and 95 other CVEs on record, and the flaw needs no authentication and no user interaction — network access to the inference API is enough. There is no public exploit, no Nuclei template, and it isn't in CISA KEV, so this reads as a low-noise availability bug rather than an active threat, and the CVSS 5.3 (impact limited to availability) reflects that. Teams running vLLM with multimodal/video inputs enabled should upgrade to 0.27.0 or later (fix in GHSA-cqm8-jxg6-fqfq / commit e23b193) and, until patched, disable or gate the DeepStream video decode path at the API gateway.
What is the risk?
Medium risk overall. Exploitability is high on paper — network-reachable, low attack complexity, no privileges or user interaction required — but the impact is scoped to availability only (no confidentiality/integrity loss), and it produces a 'partial' DoS rather than a full outage. No EPSS data, no known public exploit or scanner template, and absence from CISA KEV all point to low observed exploitation activity today. The main exposure factor is deployment posture: any vLLM instance that exposes its inference API without gateway-level request/payload controls and has multimodal/video decode reachable is exploitable by a single unauthenticated request.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | — | No patch |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Patch: upgrade to vLLM >=0.27.0 (fix in commit e23b19309b8705b21c3b3ff4129c9974ba15a419, tracked as GHSA-cqm8-jxg6-fqfq). Workaround until patched: disable the DeepStream backend / video multimodal input types if not required, or restrict/authenticate access to the inference endpoint at the API gateway. Detection: monitor GPU decode pool saturation and per-request GPU/decode resource usage, alert on abnormal video payload sizes or unauthenticated bursts of video-bearing requests, and rate-limit multimodal inference calls from unauthenticated or untrusted sources.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-78684?
vLLM's multimodal inference path fails to classify DeepStream as a GPU backend and skips pixel-limit checks, letting any unauthenticated caller activate the DeepStream decode pool and submit oversized video that saturates it, degrading service for every other concurrent request on that vLLM instance. This matters because vLLM is a widely-deployed inference engine with 128 downstream dependents and 95 other CVEs on record, and the flaw needs no authentication and no user interaction — network access to the inference API is enough. There is no public exploit, no Nuclei template, and it isn't in CISA KEV, so this reads as a low-noise availability bug rather than an active threat, and the CVSS 5.3 (impact limited to availability) reflects that. Teams running vLLM with multimodal/video inputs enabled should upgrade to 0.27.0 or later (fix in GHSA-cqm8-jxg6-fqfq / commit e23b193) and, until patched, disable or gate the DeepStream video decode path at the API gateway.
Is CVE-2026-78684 actively exploited?
No confirmed active exploitation of CVE-2026-78684 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-78684?
Patch: upgrade to vLLM >=0.27.0 (fix in commit e23b19309b8705b21c3b3ff4129c9974ba15a419, tracked as GHSA-cqm8-jxg6-fqfq). Workaround until patched: disable the DeepStream backend / video multimodal input types if not required, or restrict/authenticate access to the inference endpoint at the API gateway. Detection: monitor GPU decode pool saturation and per-request GPU/decode resource usage, alert on abnormal video payload sizes or unauthenticated bursts of video-bearing requests, and rate-limit multimodal inference calls from unauthenticated or untrusted sources.
What systems are affected by CVE-2026-78684?
This vulnerability affects the following AI/ML architecture patterns: model serving, multimodal inference pipelines.
What is the CVSS score for CVE-2026-78684?
CVE-2026-78684 has a CVSS v3.1 base score of 5.3 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029 Denial of AI Service AML.T0034.001 Resource-Intensive Queries AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
vLLM before 0.27.0 fails to properly classify DeepStream as a GPU backend and omits pixel-limit enforcement in its decode path. Unauthenticated attackers can activate DeepStream at request time to initialize the process-wide GPU decode pool and submit video that bypasses resource controls, causing partial denial of service for concurrent requests.
Exploitation Scenario
An unauthenticated attacker with network access to a public-facing vLLM inference endpoint sends a request that triggers activation of the DeepStream GPU backend, then submits a video payload that exceeds the pixel limits vLLM should — but fails to — enforce. The oversized decode job monopolizes the process-wide GPU decode pool, starving the resources other concurrent inference requests need, so legitimate users of the same vLLM instance experience degraded latency or failed responses until the malicious job clears — a classic resource-exhaustion DoS delivered through a legitimate-looking multimodal inference call.
Weaknesses (CWE)
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.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L References
Timeline
Related Vulnerabilities
CVE-2024-9053 9.8 vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm CVE-2026-25960 9.8 vllm: SSRF allows internal network access
Same package: vllm CVE-2025-47277 9.8 vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllm CVE-2024-11041 9.8 vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllm CVE-2025-32444 9.8 vLLM: RCE via pickle deserialization on ZeroMQ
Same package: vllm