CVE-2026-85673 in LLaMA-Factory
Summary
by MITRE • 09/04/2026
LLaMA-Factory contains a server-side request forgery vulnerability in the OpenAI-compatible API multimodal media URL handler that allows unauthenticated attackers to bypass SSRF validation. The check_ssrf_url guard validates URLs once but requests.get follows redirects and re-resolves DNS without re-validation, enabling attackers to use HTTP redirects or DNS rebinding to access internal addresses and cloud metadata endpoints.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in LLaMA-Factory represents a critical server-side request forgery (SSRF) flaw within its OpenAI-compatible API implementation, specifically affecting the multimodal media URL handler. This component is designed to process external URLs provided by users for image or video analysis, but it fails to adequately secure these requests against malicious manipulation. The core technical deficiency lies in the validation logic employed by the check_ssrf_url guard function. While this function performs an initial inspection of the provided Uniform Resource Locator (URL) to ensure it does not point to internal network ranges or restricted cloud metadata endpoints, it only validates the URL at a single static point in time. This approach ignores the dynamic nature of HTTP protocols and DNS resolution mechanisms, creating a significant security gap that unauthenticated attackers can exploit to bypass these protective measures entirely.
The operational mechanism of this vulnerability relies on the behavior of standard HTTP client libraries, such as Python's requests module, which automatically follow redirects by default. When an attacker submits a URL pointing to a server under their control, they can configure that external server to respond with an HTTP redirect status code, such as 301 or 302, directing the victim application to a different target address. Because the SSRF validation check occurs before this redirection takes place, the initial request appears benign and passes the security filter. However, once the requests.get method executes, it follows the redirect chain and resolves the new destination's DNS records without re-invoking the ssrf_url guard function. This lack of post-redirect validation allows the application to make internal network requests that were never explicitly checked by the security controls.
Furthermore, this vulnerability can be exacerbated through DNS rebinding techniques, where an attacker manipulates Domain Name System (DNS) responses to change the IP address associated with a domain during the course of a single session or request lifecycle. By initially resolving to an external public IP address that passes validation and subsequently changing the resolution to an internal private IP address before the connection is fully established, attackers can effectively trick the application into communicating with localhost or other restricted network segments. This capability enables unauthorized access to sensitive cloud metadata endpoints, such as those found in AWS EC2 instance metadata service (IMDSv1), which often contain temporary security credentials and configuration details that can be leveraged for further compromise of the underlying infrastructure.
The impact of this SSRF vulnerability is severe, as it allows unauthenticated actors to probe internal network services, exfiltrate sensitive data from cloud environments, or potentially pivot into more critical parts of the organization's architecture. Accessing cloud metadata endpoints alone can lead to full account takeover if temporary credentials are retrieved and used with appropriate APIs. Additionally, attackers may use this vector to scan for vulnerable internal applications, perform denial-of-service attacks against internal resources by sending excessive requests, or interact with services that are not intended to be exposed to the public internet. This represents a significant risk to data confidentiality, integrity, and availability within environments deploying LLaMA-Factory without proper network segmentation or additional security controls.
To mitigate this vulnerability, developers must implement strict validation of URLs after every redirect occurs, ensuring that each hop in the request chain is checked against allowed domains and internal IP ranges. It is also recommended to disable automatic redirection handling in HTTP client libraries when processing user-supplied URLs, forcing manual verification at each step if redirects are necessary for legitimate functionality. Implementing a allowlist approach rather than a blocklist approach can further reduce risk by explicitly defining which external domains are permitted for media fetching. Additionally, deploying network-level controls such as egress filtering and web application firewalls that inspect outbound traffic patterns can provide an additional layer of defense against SSRF attacks targeting internal resources or cloud metadata services.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF), specifically reflecting weaknesses in input validation during dynamic request processing. It also maps to MITRE ATT&CK technique T1571 Non-Standard Port and potentially T1046 Network Service Discovery if used for internal scanning, though the primary classification remains SSRF due to the abuse of server-side functionality to access unauthorized resources. The failure to validate URLs after redirection is a common pattern in web application security flaws, often categorized under CWE-20 Improper Input Validation when considering the broader context of insufficient sanitization during request execution phases. Addressing this issue requires a defense-in-depth strategy that combines robust code-level validation with network segmentation and monitoring to detect anomalous outbound traffic patterns indicative of SSRF exploitation attempts.