vLLM Cache and Resource Consumption Vulnerabilities

Remote code execution in vLLM 0.7.3 through 0.30.x lets remote, unauthenticated clients run arbitrary Python inside the API server process when a multimodal request to the /tokenize endpoint supplies a crafted mm_processor_kwargs.code_revision value, which vLLM forwards to Transformers AutoProcessor.from_pretrained and uses to select which revision of the model repository's dynamic processor code gets imported. Exploitation requires two non-default preconditions: the server must be running with trust_remote_code enabled, and the attacker must control (or be able to write) a revision in the model repository being served, so default hardened deployments with remote code disabled are not exposed. No public exploit code or confirmed active exploitation was identified at time of analysis, but the impact for exposed configurations is full confidentiality, integrity and availability loss (vendor CVSS 4.0 score 9.2; our independent CVSS 3.1 assessment of 8.1 reflects the high attack complexity created by the prerequisites).

Remote unauthenticated memory exhaustion in vLLM 0.7.3 through versions before 0.31.0 allows clients to terminate shared multimodal inference servers by supplying oversized per-request mm_processor_kwargs, such as large image sizes, patch counts, crop counts, or frame counts, to processors including Isaac, InternVL, and H2OVL. Deployments are exposed when they serve a multimodal model and accept client-controlled mm_processor_kwargs without validation; text-only models and hardened configurations that disable or clamp these parameters are not affected. No public exploit was identified at time of analysis, and the impact is availability-only, with the highest practical risk for multi-tenant or internet-exposed inference APIs.

Unauthenticated memory exhaustion in vLLM versions after 0.24.0 and before 0.31.0 can crash the API process when the MOSS-Audio model is served, because request-controlled mm_processor_kwargs values are cached in an unbounded dictionary. Attackers can send distinct or oversized mel_config values to the /tokenize endpoint, which bypasses --api-key authentication, steadily consuming host memory until the service dies. No public exploit identified at time of analysis; the vendor-released fix is vLLM 0.31.0, and only deployments actively serving MOSS-Audio with a reachable /tokenize endpoint are exposed.

Denial of service in vLLM before 0.31.0 allows remote attackers to crash the entire serving instance by forging or reusing a client-supplied multimodal UUID so the P0/P1 processor caches disagree on token placeholders and hit a fatal mismatch. The flaw is reachable only when the deployment serves a multimodal model and exposes the multimodal inference API; text-only vLLM deployments are not affected. No public exploit was identified at time of analysis, and authentication requirements are conflicting in the supplied data: the CVSS 4.0 vector is PR:L while the independent assessment uses PR:N and the description says unauthenticated, so exposure depends on whether the endpoint is protected (vLLM's default server has no authentication per the assessment).

Cache aliasing in vLLM before 0.31.0 allows authenticated users of a shared deployment to receive another request's cached processed media or reuse first-block KV cache state by supplying colliding EXIF ImageID or cache_salt values. The flaw is only exploitable when image-processing and/or prefix-KV caches are shared across distinct callers or tenants and the attacker can control the relevant cache-key inputs; single-tenant or isolated-cache deployments have no cross-request target. No public exploit identified at time of analysis; the vendor CVSS 4.0 score is 7.1, and the independent assessment rates confidentiality impact high with limited integrity impact.

Crafted /inference/v1/generate requests can permanently stall vLLM before 0.31.0 by killing the EngineCore input thread with an uncaught VLLMValidationError while /health continues to return 200. The trigger is a generate request that sets max_tokens to null-causing the min_tokens <= max_tokens validation to be skipped-together with an oversized min_tokens value, after which all subsequent generation requests hang until a manual restart. This is an availability-only flaw (CWE-248); the supplied CVSS 4.0 vector scores it 7.1 with PR:L, while our independent assessment uses CVSS 3.1 with PR:N, so authentication or network ACLs in front of the inference API materially reduce exposure, and no public exploit identified at time of analysis.

Concurrent constrained-decoding traffic against vLLM servers running versions before 0.31.0 can leave a stale token allowlist in a recycled batch slot, so a victim's unrestricted generation request is silently constrained to the attacker's token set. The flaw is in InputBatch.condense(), which recycles finished request slots without clearing allowed_token_ids; remote unauthenticated attackers who can reach the generation API, including the unauthenticated /invocations endpoint, can trigger it by submitting many concurrent constrained requests while a race with slot reuse is won. Impact is integrity-only - the victim's output is degraded or steered, but no victim data is read - and success is timing- and load-dependent (CVSS AC:H with attack requirement AT:P). No public exploit code or confirmed active exploitation has been identified at time of analysis, and the issue is fixed in vLLM 0.31.0.