AI Threat AlertCVE-2026-105753 is a denial-of-service flaw in vLLM's default multimodal cache: a rejected multimodal request leaves the frontend cache believing a media item was delivered, so a later request reusing the same media hash hits an assertion in the engine and fails. Any authenticated user with low privileges can trigger it over the network with no user interaction, and because vLLM is typically a shared inference service, one tenant can knock out availability for everyone. Severity is moderate (CVSS 6.5, availability impact only), and exploitation likelihood is currently low: EPSS is 0.00425 (65th percentile), the CVE is not in CISA KEV, and there is no public exploit or Nuclei template. Even so, vLLM has 95 downstream dependents and 134 other CVEs on record, so the blast radius is wide and the bug is easy to reproduce once the advisory is read. Upgrade to vLLM 0.28.0 or later, and until then restrict multimodal inputs to trusted clients and monitor for engine assertion failures and restarts.
What is the risk?
Medium overall. Exploitation is network-reachable, low complexity, needs only low privileges (a valid API client or access to the endpoint), and requires no user interaction. Impact is limited to availability (A:H); there is no confidentiality or integrity loss. Real-world risk rises for multi-tenant or internet-exposed vLLM deployments serving multimodal models, where one client can degrade service for all. Exploitation signals are weak today: no KEV listing, no public exploit, no scanner template, low EPSS (0.00425).
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| vLLM | pip | < 0.28.0 | 0.28.0 |
Do you use vLLM? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step1) Upgrade vllm to 0.28.0 or later (pip install -U 'vllm>=0.28.0'). 2) If immediate patching is not possible, restrict access to multimodal endpoints to authenticated, trusted clients and apply per-client rate limits and request validation at an API gateway. 3) Consider disabling or reducing multimodal caching if your deployment supports that configuration, after testing the performance impact. 4) Detect: alert on AssertionError messages containing 'Expected a cached item', unexpected engine process restarts, and spikes in rejected multimodal requests followed by failures on repeated media. 5) Run vLLM under a supervisor with automatic restart and health checks to limit outage duration. 6) Inventory downstream applications that embed vLLM and track their upgrade status.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-105753?
CVE-2026-105753 is a denial-of-service flaw in vLLM's default multimodal cache: a rejected multimodal request leaves the frontend cache believing a media item was delivered, so a later request reusing the same media hash hits an assertion in the engine and fails. Any authenticated user with low privileges can trigger it over the network with no user interaction, and because vLLM is typically a shared inference service, one tenant can knock out availability for everyone. Severity is moderate (CVSS 6.5, availability impact only), and exploitation likelihood is currently low: EPSS is 0.00425 (65th percentile), the CVE is not in CISA KEV, and there is no public exploit or Nuclei template. Even so, vLLM has 95 downstream dependents and 134 other CVEs on record, so the blast radius is wide and the bug is easy to reproduce once the advisory is read. Upgrade to vLLM 0.28.0 or later, and until then restrict multimodal inputs to trusted clients and monitor for engine assertion failures and restarts.
Is CVE-2026-105753 actively exploited?
No confirmed active exploitation of CVE-2026-105753 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-105753?
1) Upgrade vllm to 0.28.0 or later (pip install -U 'vllm>=0.28.0'). 2) If immediate patching is not possible, restrict access to multimodal endpoints to authenticated, trusted clients and apply per-client rate limits and request validation at an API gateway. 3) Consider disabling or reducing multimodal caching if your deployment supports that configuration, after testing the performance impact. 4) Detect: alert on AssertionError messages containing 'Expected a cached item', unexpected engine process restarts, and spikes in rejected multimodal requests followed by failures on repeated media. 5) Run vLLM under a supervisor with automatic restart and health checks to limit outage duration. 6) Inventory downstream applications that embed vLLM and track their upgrade status.
What systems are affected by CVE-2026-105753?
This vulnerability affects the following AI/ML architecture patterns: LLM model serving, Multimodal inference endpoints, Shared multi-tenant inference platforms, RAG pipelines, Agent frameworks backed by self-hosted vLLM.
What is the CVSS score for CVE-2026-105753?
CVE-2026-105753 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.43%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0029Denial of AI ServiceAML.T0040AI Model Inference API AccessAML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
vLLM is an inference and serving engine for large language models. Prior to 0.28.0, the default mirrored multimodal LRU cache can commit a media hash in the frontend sender cache during multimodal rendering and before engine admission, while the engine receiver cache never receives the payload if that request is rejected. A later request reusing the same media hash causes MultiModalProcessorSenderCache to send no payload and MultiModalReceiverCache to reach an assertion with the message "Expected a cached item," producing a shared-service availability failure. This issue is fixed in version 0.28.0.
Exploitation Scenario
An attacker with a low-privilege API key on a shared vLLM service submits a multimodal request with an image that is later rejected (for example, it exceeds an admission limit or the queue is full), but the frontend has already cached the image's hash. The attacker then sends a second request referencing the same media hash. The frontend sends no payload because it thinks the engine has it, the engine's receiver cache has no entry, and the assertion fires, crashing or failing the engine. Repeating this cycle keeps the service down for every tenant, disrupting production chatbots, RAG pipelines, and agents relying on the endpoint.
Weaknesses (CWE)
CWE-617 — Reachable Assertion: The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.
- [Implementation] Make sensitive open/close operation non reachable by directly user-controlled data (e.g. open/close resources)
- [Implementation] Perform input validation on user data.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:HReferences
- github.com/advisories/GHSA-ph3r-5jfg-f84f
- github.com/vllm-project/vllm/commit/396204230423b7cc6798300926b8fa30190d26a9
- github.com/vllm-project/vllm/pull/46747
- github.com/vllm-project/vllm/pull/51897
- github.com/vllm-project/vllm/releases/tag/v0.28.0
- github.com/vllm-project/vllm/security/advisories/GHSA-ph3r-5jfg-f84f
Timeline
Related Vulnerabilities
CVE-2026-6173210.0Decepticon: ChatML token injection yields sandbox RCE
Same package: vllmCVE-2024-110419.8vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllmCVE-2026-259609.8vllm: SSRF allows internal network access
Same package: vllmCVE-2025-472779.8vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllmCVE-2024-90539.8vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm