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
This flaw lets an authenticated or otherwise permitted user make a vulnerable vLLM server fetch attacker-chosen URLs. In practice, the model-serving server could be turned into a bridge to internal systems, especially inside Kubernetes or llm-d environments. The main business risk is exposure of internal services or instability in AI-serving infrastructure.
Executive priority
Treat as a high-priority AI infrastructure fix, especially for shared or containerized model-serving platforms. Patch promptly and verify network segmentation, because the vulnerable server may have more internal reach than the original user.
Technical view
vLLM before 0.14.1 has an SSRF in MediaConnector multimodal URL loading. load_from_url and load_from_url_async use different Python URL parsers when enforcing host restrictions. Backslash handling differences can bypass hostname restriction, allowing arbitrary requests from the vLLM server to internal network resources.
Likely exposure
Exposure is most likely where vLLM versions before 0.14.1 accept user-supplied media URLs through multimodal features. Containerized deployments and llm-d environments have higher impact because the vLLM pod may reach internal pods, services, or management endpoints.
Exploitation context
The bundle marks KEV as false and provides no evidence of active exploitation. Exploitation requires network access and low privileges, with no user interaction. The cited description says abuse could scan internal networks, interact with other pods, affect availability, or access sensitive internal data.
Researcher notes
Focus review on MediaConnector URL parsing and hostname restriction behavior in pre-0.14.1 vLLM. The evidence supports SSRF via parser inconsistency, but the bundle does not prove public exploitation or provide complete downstream product impact beyond listed vLLM and Red Hat advisories.
Mitigation direction
Upgrade vLLM to version 0.14.1 or later.
Apply applicable Red Hat advisories for packaged affected components.
Restrict vLLM pod egress to required destinations only.
Limit or disable user-supplied remote media URL ingestion where feasible.
Review vendor guidance for environment-specific hardening.
Validation and detection
Inventory vLLM deployments and confirm versions are 0.14.1 or later.
Identify services accepting user-controlled media URLs for multimodal processing.
Review Kubernetes or container egress rules for vLLM pods.
Check logs for unexpected internal requests originating from vLLM servers.
Confirm relevant Red Hat errata are applied where Red Hat packages are used.
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.