CVE-2025-62372: vLLM security flaw enables

CISO Take

If your organization runs vLLM for multimodal inference, patch to 0.11.1 immediately — any authenticated API user can crash the entire serving engine with a single malformed request, taking down all dependent services. This is a hard availability risk with no workaround other than restricting API access to fully trusted callers. Patch-or-restrict is the only acceptable posture.

What is the risk?

Medium-severity availability risk with high practical impact for production AI serving environments. CVSS A:H and AC:L means the DoS is reliable and repeatable; any low-privilege user (including trial accounts or internal dev teams) can trigger it. EPSS 0.00083 indicates no active exploitation yet, but the technique is trivially reproducible once known. For organizations using vLLM as the backbone of multimodal AI services, the blast radius is the entire inference fleet — not just a single request.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	—	No patch
83.4K 130 dependents Pushed 3d ago 34% patched ~32d to patch Full package profile →
vLLM	pip	>= 0.5.5, < 0.11.1	`0.11.1`
83.4K 130 dependents Pushed 3d ago 34% patched ~32d to patch Full package profile →

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 25% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C None

I None

A High

What should I do?

1 step

1) Patch: upgrade vLLM to >= 0.11.1 (pip install vllm==0.11.1). 2) If patching is delayed, restrict vLLM API access to known trusted callers via network policy or API gateway — remove low-privilege or anonymous access. 3) Add input validation at the API gateway layer to reject embedding payloads with unexpected shape dimensions before they reach vLLM. 4) Implement process supervision (systemd, Kubernetes liveness probes) to auto-restart the vLLM engine on crash and alert on restart events. 5) Monitor vLLM process crash logs for unexpected terminations as a detection signal for exploitation attempts.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Inference Framework AML.T0029 - Denial of AI Service AML.T0034 - Cost Harvesting AML.T0040 - AI Model Inference API Access AML.T0043 - Craft Adversarial Data AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system input validation and robustness

NIST AI RMF

MANAGE-2.4 - Residual risks are managed

OWASP LLM Top 10

LLM04 - Model Denial of Service

Frequently Asked Questions

What is CVE-2025-62372?

If your organization runs vLLM for multimodal inference, patch to 0.11.1 immediately — any authenticated API user can crash the entire serving engine with a single malformed request, taking down all dependent services. This is a hard availability risk with no workaround other than restricting API access to fully trusted callers. Patch-or-restrict is the only acceptable posture.

Is CVE-2025-62372 actively exploited?

No confirmed active exploitation of CVE-2025-62372 has been reported, but organizations should still patch proactively.

How to fix CVE-2025-62372?

1) Patch: upgrade vLLM to >= 0.11.1 (pip install vllm==0.11.1). 2) If patching is delayed, restrict vLLM API access to known trusted callers via network policy or API gateway — remove low-privilege or anonymous access. 3) Add input validation at the API gateway layer to reject embedding payloads with unexpected shape dimensions before they reach vLLM. 4) Implement process supervision (systemd, Kubernetes liveness probes) to auto-restart the vLLM engine on crash and alert on restart events. 5) Monitor vLLM process crash logs for unexpected terminations as a detection signal for exploitation attempts.

What systems are affected by CVE-2025-62372?

This vulnerability affects the following AI/ML architecture patterns: model serving, multimodal AI pipelines, inference endpoints, RAG pipelines with multimodal inputs, LLM-as-a-service platforms.

What is the CVSS score for CVE-2025-62372?

CVE-2025-62372 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.33%.

What is the AI security impact?

Affected AI Architectures

model servingmultimodal AI pipelinesinference endpointsRAG pipelines with multimodal inputsLLM-as-a-service platforms

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0034 Cost Harvesting

AML.T0040 AI Model Inference API Access

AML.T0043 Craft Adversarial Data

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE-2.4

OWASP LLM Top 10: LLM04

What are the technical details?

Original Advisory

vLLM is an inference and serving engine for large language models (LLMs). From version 0.5.5 to before 0.11.1, users can crash the vLLM engine serving multimodal models by passing multimodal embedding inputs with correct ndim but incorrect shape (e.g. hidden dimension is wrong), regardless of whether the model is intended to support such inputs (as defined in the Supported Models page). This issue has been patched in version 0.11.1.

Exploitation Scenario

An attacker with any level of API access to a vLLM multimodal endpoint — including a free-tier or internal dev account — crafts a POST request to the inference API submitting a multimodal embedding tensor with the correct number of dimensions (correct ndim) but wrong hidden dimension size. vLLM's improper array index validation (CWE-129) fails to catch the shape mismatch, causing an unhandled exception that crashes the engine process. The attacker can repeat this in a loop to cause sustained denial of service, or use it as a one-shot to disrupt a critical inference pipeline during a sensitive business window.

Weaknesses (CWE)

CWE-129 Improper Validation of Array Index Primary CWE-129 Improper Validation of Array Index

CWE-129 — Improper Validation of Array Index: The product uses untrusted input when calculating or using an array index, but the product does not validate or incorrectly validates the index to ensure the index references a valid position within the array.

[Architecture and Design] Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that using a framework does not automatically address all input validation problems; be mindful of weaknesses that could arise from misusing the framework itself (CWE-1173).
[Architecture and Design] For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server. Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.

Source: MITRE CWE corpus.