Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-04T15:17:45.440Z",
  "pubdate": "2026-09-04T15:17:45.440Z",
  "executiveSummary": "LLaMA-Factory contains a critical Server-Side Request Forgery (SSRF) vulnerability within its OpenAI-compatible API multimodal media URL handler. The vulnerability stems from improper validation logic that fails to account for redirect chains and DNS rebinding during the fetch process.\nUnauthenticated attackers can exploit this flaw to bypass existing security controls, effectively gaining the ability to perform requests to internal infrastructure or restricted cloud metadata services (e.g., 169.254.169.254).\nThe risk is severe, as it permits attackers to interact with internal networked services that are otherwise shielded from public access. By leveraging HTTP redirects or DNS rebinding, an attacker can pivot their reach into the private environment where the LLaMA-Factory instance is deployed. Successful exploitation requires no authentication, making it a high-priority risk for deployments exposed to untrusted networks.",
  "technicalDetails": "The vulnerability resides in the check_ssrf_url guard function responsible for validating user-supplied URLs in the multimodal media handler. The root cause is a time-of-check to time-of-use (TOCTOU) deficiency combined with the misconfiguration of the HTTP client used for media retrieval.\nWhile the application performs an initial check on the provided URL, the subsequent use of the requests.get function introduces an insecure execution path. The requests library follows HTTP redirects by default; however, the validation logic is not re-applied after a redirect occurs. Consequently, an attacker can provide a seemingly benign URL that immediately issues a 302/307 redirect to an internal resource (e.g., http://127.0.0.1:8080 or a cloud metadata endpoint). Because the security guard has already completed its validation, the fetch operation proceeds to the redirected internal address without further inspection.\nFurthermore, the implementation is susceptible to DNS rebinding attacks. If the initial check performs a DNS resolution and validation, but the requests.get call triggers a subsequent resolution of the same hostname, an attacker can modify the DNS record during the interim window. By setting a very low Time-to-Live (TTL) on the malicious domain, the attacker can ensure that the initial validation check resolves to an external, benign IP, while the subsequent fetch operation resolves to an internal, restricted IP.\nAttack Flow: 1) The attacker sends an API request to the LLaMA-Factory OpenAI-compatible interface, providing a malicious multimodal URL. 2) The check_ssrf_url function inspects the URL, which passes as it resolves to an external server controlled by the attacker. 3) The requests.get handler fetches the URL and processes a redirect directive returned by the attacker's server. 4) The library follows the redirect to an internal target, bypassing the initial validation guard. 5) The server-side environment executes the request, potentially leaking internal data or performing unauthorized operations on internal APIs or cloud metadata services. This requires no specific privileges and can be executed over any network path capable of reaching the LLaMA-Factory instance."
}