CVE-2025-6242: vLLM SSRF — HIGH

CISO Take

Any vLLM deployment running multimodal workloads between v0.5.0 and v0.11.0 is vulnerable to server-side request forgery via crafted media URLs — an authenticated user can pivot to internal APIs, cloud metadata endpoints, or other services co-located with the inference server. Patch to v0.11.0 immediately; if patching is not possible, enforce strict egress filtering at the network layer and disable multimodal endpoints. This is a particularly dangerous vector in cloud-hosted inference clusters where IAM credential theft via metadata service (169.254.169.254) is trivial once SSRF is achieved.

What is the risk?

CVSS 7.1 High with high attack complexity and low privilege requirement. The high complexity rating reflects the need to understand internal network topology, but any authenticated API user in a multi-tenant or shared inference deployment can attempt exploitation. EPSS 0.00048 suggests no widespread active exploitation at time of publication. However, vLLM is one of the most widely deployed open-source LLM inference engines, and SSRF in inference infrastructure is disproportionately dangerous: these servers typically run with elevated IAM roles, have broad internal network reach, and are exposed to untrusted user input by design. Cloud-native deployments (EKS, GKE, AKS) face highest risk due to reachable metadata APIs.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
vLLM	pip	>= 0.5.0, < 0.11.0	`0.11.0`
83.4K 130 dependents Pushed 2d ago 34% patched ~32d to patch Full package profile →

Do you use vLLM? You're affected.

How severe is it?

CVSS 3.1

7.1 / 10

EPSS

0.2%

chance of exploitation in 30 days

Higher than 13% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC High

PR Low

UI None

S Unchanged

C High

I Low

A High

What should I do?

6 steps

PATCH

Upgrade vLLM to >= 0.11.0 immediately — this is the only full remediation.
WORKAROUND (if patching is delayed): Disable multimodal API endpoints at the reverse proxy/gateway layer; reject requests containing media URL parameters.
NETWORK CONTROLS

Implement egress filtering on inference server instances — block outbound access to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local (169.254.0.0/16) from vLLM processes. Use cloud security groups or network policies to enforce this.
CLOUD

Enable IMDSv2 on AWS (requires session-oriented tokens, not fetchable via simple SSRF); equivalent hardening on GCP/Azure.
DETECTION

Alert on outbound HTTP requests from inference servers to metadata endpoints or internal subnets; log all media URL parameters in API requests for anomaly review.
AUDIT

Review current vLLM version across all environments including dev/staging where cloud credentials may be present.

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?

Data Extraction Auth Bypass Inference Framework AML.T0025 - Exfiltration via Cyber Means AML.T0040 - AI Model Inference API Access AML.T0049 - Exploit Public-Facing Application AML.T0075 - Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6 - AI system security

NIST AI RMF

MANAGE-2.2 - Mechanisms are in place to address residual risks

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2025-6242?

Any vLLM deployment running multimodal workloads between v0.5.0 and v0.11.0 is vulnerable to server-side request forgery via crafted media URLs — an authenticated user can pivot to internal APIs, cloud metadata endpoints, or other services co-located with the inference server. Patch to v0.11.0 immediately; if patching is not possible, enforce strict egress filtering at the network layer and disable multimodal endpoints. This is a particularly dangerous vector in cloud-hosted inference clusters where IAM credential theft via metadata service (169.254.169.254) is trivial once SSRF is achieved.

Is CVE-2025-6242 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2025-6242, increasing the risk of exploitation.

How to fix CVE-2025-6242?

1. PATCH: Upgrade vLLM to >= 0.11.0 immediately — this is the only full remediation. 2. WORKAROUND (if patching is delayed): Disable multimodal API endpoints at the reverse proxy/gateway layer; reject requests containing media URL parameters. 3. NETWORK CONTROLS: Implement egress filtering on inference server instances — block outbound access to RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and link-local (169.254.0.0/16) from vLLM processes. Use cloud security groups or network policies to enforce this. 4. CLOUD: Enable IMDSv2 on AWS (requires session-oriented tokens, not fetchable via simple SSRF); equivalent hardening on GCP/Azure. 5. DETECTION: Alert on outbound HTTP requests from inference servers to metadata endpoints or internal subnets; log all media URL parameters in API requests for anomaly review. 6. AUDIT: Review current vLLM version across all environments including dev/staging where cloud credentials may be present.

What systems are affected by CVE-2025-6242?

This vulnerability affects the following AI/ML architecture patterns: LLM inference serving, multimodal AI pipelines, model serving, RAG pipelines with image or document processing, agent frameworks using vLLM as inference backend.

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

CVE-2025-6242 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.23%.

What is the AI security impact?

Affected AI Architectures

LLM inference servingmultimodal AI pipelinesmodel servingRAG pipelines with image or document processingagent frameworks using vLLM as inference backend

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0040 AI Model Inference API Access

AML.T0049 Exploit Public-Facing Application

AML.T0075 Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

A Server-Side Request Forgery (SSRF) vulnerability exists in the MediaConnector class within the vLLM project's multimodal feature set. The load_from_url and load_from_url_async methods fetch and process media from user-provided URLs without adequate restrictions on the target hosts. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources.

Exploitation Scenario

An attacker with a valid (potentially free-tier or stolen) API key to a vLLM multimodal inference endpoint submits an image generation or analysis request where the media URL points to http://169.254.169.254/latest/meta-data/iam/security-credentials/. The vLLM server fetches the URL server-side via MediaConnector.load_from_url(), retrieves the AWS IAM role credentials, and the response content may be returned to the attacker directly or inferred from model behavior. With IAM credentials, the attacker escalates to S3 bucket access, other AWS services, or pivots further into the internal infrastructure. In a Kubernetes environment, the attacker could target http://kubernetes.default.svc/api/v1/secrets to harvest cluster secrets. High attack complexity reflects the need to craft the request correctly and know the target internal topology, but this is well-documented in public SSRF playbooks.

Weaknesses (CWE)

CWE-601 URL Redirection to Untrusted Site ('Open Redirect') Primary CWE-918 Server-Side Request Forgery (SSRF) Primary CWE-918 Server-Side Request Forgery (SSRF)

CWE-601 — URL Redirection to Untrusted Site ('Open Redirect'): The web application accepts a user-controlled input that specifies a link to an external site, and uses that link in a redirect.

[Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis
[Architecture and Design] Use an intermediate disclaimer page that provides the user with a clear warning that they are leaving the current site. Implement a long timeout before the redirect occurs, or force the user to click on the link. Be careful to avoid XSS problems (CWE-79) when generating the disclaimer page.

Source: MITRE CWE corpus.