CVE-2026-105753: vLLM Engine DOS Vulnerability

CVE-2026-105753 Overview

vLLM is an inference and serving engine for large language models. CVE-2026-105753 is a denial-of-service vulnerability affecting vLLM versions prior to 0.28.0. The flaw resides in the default mirrored multimodal LRU cache used during multimodal rendering. When the frontend sender cache commits a media hash before engine admission, and the request is subsequently rejected, the engine receiver cache never receives the payload. A later request reusing the same media hash triggers an assertion failure in MultiModalReceiverCache with the message Expected a cached item, crashing the shared inference service.

Critical Impact
An authenticated low-privileged user can crash the shared vLLM inference service by triggering cache drift between the frontend sender cache and engine receiver cache, resulting in high availability impact.

Affected Products

vLLM inference and serving engine versions prior to 0.28.0
Deployments using the default mirrored multimodal LRU cache
Multi-tenant vLLM services handling multimodal requests

Discovery Timeline

2026-10-05 - CVE-2026-105753 published to NVD
2026-10-06 - Last updated in NVD database

Technical Details for CVE-2026-105753

Vulnerability Analysis

The vulnerability stems from a state-synchronization defect between two cooperating caches in vLLM's multimodal pipeline. The P0 (frontend) MultiModalProcessorSenderCache maintains a metadata-only shadow of the P1 (engine) MultiModalReceiverCache. On a shadow hit, the frontend sends data=None, expecting the engine to resolve the payload from its own cache.

The two caches update in different orders across processes and can drift. When the frontend commits a media hash before the engine admits the corresponding request, a rejection leaves the engine without the payload. A follow-up request reusing that hash reaches an assertion with Expected a cached item, terminating the engine process. The weakness is classified as [CWE-617] Reachable Assertion.

Root Cause

The root cause is improper cache state coordination. The sender cache treats admission as implicit, committing hash metadata before confirming receiver-side storage. Rejected requests create orphaned shadow entries. Because the receiver uses an assertion rather than a recoverable error, any subsequent lookup for a drifted hash halts the shared service.

Attack Vector

The attack requires network access and low privileges, with no user interaction. An attacker submits a multimodal request crafted to be rejected after the frontend commits its hash. A second request reusing the same media hash triggers the assertion. Successful exploitation produces a shared-service availability failure affecting all tenants on the vLLM instance.

python

class MultiModalCacheMissError(RuntimeError):
    """Raised by the P1 receiver cache when items are requested with no data and
    are not cached.

    P0 (frontend) keeps a metadata-only shadow of P1 (engine) and sends
    ``data=None`` on a shadow hit. The two caches are updated in different orders
    across processes, so they can drift -- leaving P0 referencing items P1 has
    evicted. Raising (instead of asserting) lets the engine return a retryable
    response and have P0 drop the stale entries
    (``BaseMultiModalProcessorCache.invalidate``) so the client resends the data.
    Carries every drifted ``mm_hash`` in the request so P0 can drop them all in one
    pass -- one retry then recovers the whole request, not one item per retry.
    """

    def __init__(self, mm_hashes: list[str]) -> None:
        super().__init__(
            f"Multi-modal items {mm_hashes} are not in the receiver (P1) cache and "
            "no data was provided to recompute them (P0/P1 cache drift); the request "
            "should be retried with the multi-modal data attached."
        )
        self.mm_hashes = mm_hashes

Source: GitHub Commit 39620423. The patch replaces the hard assertion with a recoverable MultiModalCacheMissError, enabling retry with the full payload instead of terminating the service.

Detection Methods for CVE-2026-105753

Indicators of Compromise

vLLM engine process crashes or restarts correlated with multimodal API requests
Log entries containing the assertion message Expected a cached item
Repeated client requests reusing identical multimodal content hashes before engine admission completes
Unexpected AssertionError traces originating in MultiModalReceiverCache

Detection Strategies

Monitor vLLM service logs for Expected a cached item strings and correlate with request IDs and originating client identities
Track engine process restart counts and uptime metrics; sudden drops indicate potential exploitation
Alert on request patterns that submit a multimodal request followed by rejection and a near-immediate retry using the same media hash

Monitoring Recommendations

Instrument multimodal request latency, rejection rate, and cache hit/miss counters at both P0 and P1 layers
Forward vLLM stdout, stderr, and crash dumps to a centralized logging platform for retention and query
Establish availability SLOs on inference endpoints and page on-call when crash loops exceed baseline

How to Mitigate CVE-2026-105753

Immediate Actions Required

Upgrade all vLLM deployments to version 0.28.0 or later, which replaces the assertion with a retryable MultiModalCacheMissError
Audit API access controls to ensure only trusted authenticated users can submit multimodal requests
Enable automatic process supervision so engine crashes recover quickly while patching is scheduled

Patch Information

The fix is included in vLLM Release v0.28.0. Technical details are available in GitHub Pull Request #46747, GitHub Pull Request #51897, and GitHub Security Advisory GHSA-ph3r-5jfg-f84f. The patch introduces MultiModalCacheMissError so the engine returns a retryable response, allowing the frontend to invalidate drifted entries via BaseMultiModalProcessorCache.invalidate and resend the payload.

Workarounds

Disable the mirrored multimodal LRU cache if the deployment can tolerate the performance cost until patching is complete
Restrict multimodal endpoint access to trusted clients using network segmentation and API authentication
Apply rate limiting on multimodal submissions to reduce the frequency of potential drift conditions

bash

# Upgrade vLLM to the patched release
pip install --upgrade "vllm>=0.28.0"

# Verify the installed version
python -c "import vllm; print(vllm.__version__)"