Description

OGX (formerly Llama Stack, affected at commit fbe8e0f) contains an unauthenticated server-side request forgery vulnerability in the OpenAI-compatible POST /v1/responses endpoint. MCP tool definitions accept a server_url parameter (along with headers and authorization values) that is fetched server-side without destination validation; the existing validate_url_not_private() guard used for other URL inputs is not applied to server_url. On the default starter configuration, which runs without authentication, a remote unauthenticated attacker can cause the server to open connections to arbitrary internal addresses (including cloud metadata endpoints such as http://169.254.169.254/) and forward attacker-supplied headers and bearer tokens to those destinations.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-04T15:17:44.397Z",
  "pubdate": "2026-09-04T15:17:44.397Z",
  "executiveSummary": "OGX (formerly Llama Stack), specifically commit fbe8e0f, is vulnerable to an unauthenticated Server-Side Request Forgery (SSRF) flaw within the POST /v1/responses endpoint. The vulnerability arises from the improper handling of the 'server_url' parameter within MCP tool definitions, which lacks necessary destination validation.\nThis flaw allows a remote, unauthenticated attacker to force the server to initiate arbitrary outbound HTTP requests to internal network resources, including cloud-native metadata services like http://169.254.169.254/. By leveraging this capability, an attacker can bypass network boundaries, exfiltrate sensitive environment metadata, or perform reconnaissance on internal infrastructure.\nThe risk is significantly elevated in default starter configurations where authentication is disabled, granting potential adversaries direct access to the vulnerable endpoint. Successful exploitation enables the exfiltration of sensitive headers and bearer tokens by proxying requests through the vulnerable OGX instance, effectively transforming the server into an internal network proxy for unauthorized operations.",
  "technicalDetails": "The vulnerability resides in the request processing logic of the POST /v1/responses endpoint within the OGX framework at commit fbe8e0f. The application facilitates the use of MCP (Model Context Protocol) tool definitions, which permit users to specify a 'server_url' along with associated headers and authorization values. The root cause is the absence of a strict URL validation mechanism, specifically the failure to apply the existing 'validate_url_not_private()' function to the 'server_url' parameter.\nWhile other input vectors within the application correctly sanitize URLs to prevent access to private IP ranges and internal network endpoints, the 'server_url' field is processed without such constraints. This oversight allows an attacker to inject arbitrary internal or external URIs into the request payload.\nThe attack flow proceeds as follows: First, an unauthenticated attacker crafts a malicious POST request to the /v1/responses endpoint. Within the request body, the attacker defines an MCP tool configuration where the 'server_url' is set to a restricted target, such as the cloud metadata service IP (http://169.254.169.254/). Second, the OGX server receives this request and, upon attempting to invoke the specified tool, performs a server-side request to the attacker-supplied URL. Third, because the server initiates this request, it effectively executes the call from the context of the host environment. Finally, if headers or bearer tokens are included in the MCP tool definition, the server attaches these values to the outgoing request, allowing the attacker to interact with the target resource using the server's identity or transmitted credentials.\nThe impact of this SSRF is critical. It enables attackers to query internal services that are not exposed to the public internet, bypass firewall rules that rely on source IP address validation, and potentially steal cloud instance identity credentials from metadata services. Furthermore, by reflecting these requests, the attacker can manipulate the server to interact with arbitrary services, leading to potential data exfiltration or unauthorized actions within the internal network segment. The lack of authentication in the default configuration lowers the barrier to entry, enabling widespread reconnaissance and service exploitation by any entity capable of reaching the server over the network."
}