Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:LSummary
CVE-2026-25960 is a high-severity SSRF (CWE-918) vulnerability in Vllm Vllm. Its CVSS base score is 7.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 43th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
This vulnerability is AI-related — categorised as NLP and Transformers; in the Supply Chain and Deployment risk domain.
The strongest mitigations our analysis identified map to AC-4 (Information Flow Enforcement) and SA-11 (Developer Testing and Evaluation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-25960 is a server-side request forgery (SSRF) protection bypass vulnerability in vLLM, an inference and serving engine for large language models (LLMs). The issue affects vLLM version 0.17.0 and stems from a fix for the prior CVE-2026-24779 that was introduced in version 0.15.1. Specifically, the SSRF protection in the load_from_url_async method validates user-provided URLs using urllib3.util.parse_url() to extract the hostname. However, the method performs actual HTTP requests via aiohttp, which uses the yarl library for URL parsing, leading to inconsistent behavior that allows bypasses. The vulnerability carries a CVSS v3.1 base score of 7.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:L) and maps to CWE-918.
An attacker requires low privileges (PR:L) to exploit this vulnerability over the network (AV:N) with low attack complexity (AC:L) and no user interaction (UI:N). By supplying a malicious URL to the load_from_url_async method, the attacker can evade hostname validation, tricking the vLLM server into issuing requests to unauthorized destinations, such as internal network resources. Successful exploitation results in high confidentiality impact (C:H) with low availability impact (A:L) and no integrity impact (I:N), potentially exposing sensitive data.
Mitigation details are outlined in vLLM security advisories GHSA-qh4c-xf7m-gxfc and GHSA-v359-jj2v-j536, along with the fixing commit 6f3b2047abd4a748e3db4a68543f8221358002c0 and pull request #34743. Security practitioners should apply these updates to eliminate the parsing discrepancy and restore effective SSRF protection.
This vulnerability is notable in AI/ML contexts, as vLLM powers LLM inference and serving deployments that may handle remote model loading, increasing exposure in production environments.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-10356
Vulnerability Data
vLLM is an inference and serving engine for large language models (LLMs). The SSRF protection fix for CVE-2026-24779 add in 0.15.1 can be bypassed in the load_from_url_async method due to inconsistent URL parsing behavior between the validation layer and the…
more
actual HTTP client. The SSRF fix uses urllib3.util.parse_url() to validate and extract the hostname from user-provided URLs. However, load_from_url_async uses aiohttp for making the actual HTTP requests, and aiohttp internally uses the yarl library for URL parsing. This vulnerability in 0.17.0.
- CWE(s)
AI Security AnalysisAI
- AI Category
- NLP and Transformers
- Risk Domain
- Supply Chain and Deployment
- OWASP Top 10 for LLMs 2025
- None mapped
- Classification Reason
- Matched keywords: llms, vllm
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.3.6V1.5.3V5.3.2V10.4.7
Mitigating Controls (NIST 800-53 r5) AI
Information flow enforcement can restrict which destinations the server is allowed to contact on behalf of users.
Developer testing across OS versions can reveal behavioral differences caused by the inconsistent function.
Input validation directly stops untrusted URLs from being accepted and fetched without destination checks.
Documented development standards and tools can prohibit or replace functions known to have inconsistent implementations.
Engineering principles can require use of portable, consistently implemented functions across platforms.
Boundary protection limits the network reach of server-initiated requests even if SSRF occurs.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure development practices directly include input validation and destination allow-listing that prevent SSRF.
Runtime monitoring of web applications and services can detect anomalous outbound requests indicative of SSRF.
Vulnerability identification processes can discover and record SSRF flaws in web applications.
Network segmentation and egress controls can limit the damage from successful SSRF requests.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing can surface cross-platform inconsistencies but does not prevent their introduction in code.
Operational threat data describing SSRF campaigns can be used to tighten outbound-request allow-lists and detection rules before attackers exploit them.
Secure SDLC requires consistent API selection and platform abstraction, reducing use of inconsistently implemented functions.
Secure architecture principles include portable abstractions and avoiding platform-specific calls with divergent behavior.
Secure coding standards explicitly prohibit or wrap functions known to behave differently across OSes and versions.