Raw vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:LSummary
CVE-2026-24779 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 42th 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 SI-10 (Information Input Validation) — 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-24779 is a Server-Side Request Forgery (SSRF) vulnerability, classified under CWE-918, affecting vLLM, an inference and serving engine for large language models (LLMs), specifically in the MediaConnector class within its multimodal feature set prior to version 0.14.1. The issue arises in the load_from_url and load_from_url_async methods, which process user-provided URLs for media loading and apply host restrictions using different Python parsing libraries. These libraries interpret backslashes differently, enabling attackers to bypass the host restriction and force the vLLM server to make unintended requests.
Attackers with low privileges (PR:L) who can supply malicious URLs to the affected methods can exploit this vulnerability over the network (AV:N) with low complexity (AC:L) and no user interaction (UI:N). Successful exploitation allows the vLLM server to be coerced into issuing arbitrary requests to internal network resources, with a CVSS v3.1 base score of 7.1 (C:H/I:N/A:L). This is especially severe in containerized deployments like llm-d, where a compromised vLLM pod could scan the internal network, interact with other pods, access sensitive data, or cause denial of service—for instance, by sending malicious requests to an llm-d management endpoint that falsely reports metrics like KV cache state, leading to system instability.
The vLLM project addressed this in version 0.14.1 via a patch detailed in GitHub commit f46d576c54fb8aeec5fc70560e850bed38ef17d7 and pull request #32746, with full advisory information available at GHSA-qh4c-xf7m-gxfc. Security practitioners should upgrade to v0.14.1 or later to mitigate the risk.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-4711
Vulnerability Data
vLLM is an inference and serving engine for large language models (LLMs). Prior to version 0.14.1, 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 obtain…
more
and process media from URLs provided by users, using different Python parsing libraries when restricting the target host. These two parsing libraries have different interpretations of backslashes, which allows the host name restriction to be bypassed. This allows an attacker to coerce the vLLM server into making arbitrary requests to internal network resources. This vulnerability is particularly critical in containerized environments like `llm-d`, where a compromised vLLM pod could be used to scan the internal network, interact with other pods, and potentially cause denial of service or access sensitive data. For example, an attacker could make the vLLM pod send malicious requests to an internal `llm-d` management endpoint, leading to system instability by falsely reporting metrics like the KV cache state. Version 0.14.1 contains a patch for the issue.
- 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: llm, 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.
Input validation directly stops untrusted URLs from being accepted and fetched without destination checks.
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.
Operational threat data describing SSRF campaigns can be used to tighten outbound-request allow-lists and detection rules before attackers exploit them.