CVE-2026-24779: vLLM vulnerable to Server-Side Request Forgery (SSRF) in `MediaConnector`
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 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.
Security readout for executives and security teams
Plain-English summary
CVE-2026-24779 lets an authenticated or otherwise permitted user make vulnerable vLLM servers fetch attacker-supplied media URLs in a way that can bypass host restrictions. Business risk is internal network reachability from an AI serving pod, including sensitive services, management endpoints, or denial-of-service effects. vLLM 0.14.1 contains a patch.
Executive priority
Treat this as a near-term remediation item for AI serving environments, especially Kubernetes or llm-d-style deployments. It is high severity because the vulnerable service may become a bridge into internal systems, even without public internet exposure.
Technical view
vLLM before 0.14.1 has SSRF in the multimodal MediaConnector load_from_url and load_from_url_async paths. URL host restrictions can be bypassed because different Python parsing libraries interpret backslashes differently. Impact is arbitrary server-side requests from the vLLM process to internal resources. CVSS is 7.1 high under CWE-918.
Likely exposure
Exposure is most likely where vLLM before 0.14.1 accepts user-provided media URLs for multimodal processing and the server or pod can reach internal services. Containerized deployments are emphasized because a compromised pod may reach other pods or management endpoints.
Exploitation context
The source bundle does not show KEV listing or confirmed active exploitation. The vulnerability is network-reachable, low-complexity, requires privileges, and needs no user interaction. Practical impact depends on what internal resources the vLLM runtime can reach.
Researcher notes
Focus on URL parsing and host restriction behavior in MediaConnector, but avoid offensive testing against production. The provided evidence supports SSRF via parser inconsistency and a fixed upstream version. Product-specific exposure beyond vllm-project vLLM and referenced Red Hat advisories is not established here.
Mitigation direction
Upgrade vLLM to version 0.14.1 or later.
Apply relevant Red Hat errata if using Red Hat-packaged affected components.
Restrict outbound network access from vLLM pods to only required destinations.
Block vLLM access to internal metadata and management endpoints.
Disable or tightly gate user-supplied remote media URL fetching if unnecessary.
Validation and detection
Inventory vLLM deployments and confirm versions are 0.14.1 or later.
Identify services accepting multimodal requests with user-provided media URLs.
Review pod or host egress policies for internal network reachability.
Check logs for unusual outbound requests originating from vLLM services.
Verify vendor advisories applicable to your packaging have been applied.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · medium confidence lookup
CWE-918: Information exposure and cloud metadata lookup
Information exposure and SSRF weaknesses can make discovery, cloud metadata, and credential material review relevant. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references SSRF or metadata access, so cloud discovery and credential material review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-918 · source CWE mapping
Server-Side Request Forgery (SSRF)
Server-Side Request Forgery (SSRF) represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.