CVE-2026-85666 in OGX
Summary
by MITRE • 09/04/2026
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.
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 OGX, formerly known as Llama Stack, represents a critical server-side request forgery flaw within the OpenAI-compatible POST /v1/responses endpoint. This issue stems from an improper validation of user-controlled input specifically related to MCP tool definitions that accept a server_url parameter. While the application implements security controls such as validate_url_not_private() for other URL inputs to prevent access to internal or private network ranges, this specific guard is not applied to the server_url field. Consequently, when a client submits a request containing a maliciously crafted server_url, the backend processes it without verifying whether the destination address belongs to an internal subnet, loopback interface, or cloud metadata service. This oversight allows for unrestricted outbound connections initiated by the application itself, effectively turning the vulnerable endpoint into a proxy that can reach resources not intended to be accessible from external networks.
From an operational perspective, this vulnerability enables unauthenticated remote attackers to leverage the server as a pivot point for accessing sensitive internal infrastructure. In default configurations where authentication is disabled, any internet-facing user can exploit this flaw without providing credentials. The attacker can direct the vulnerable service to connect with cloud metadata endpoints such as http://169.254.169.254/, which are commonly used by virtual machines and containers to retrieve instance-specific data including IAM roles, security tokens, and configuration details. By forwarding these requests, an attacker can exfiltrate highly sensitive credentials that grant further access to cloud resources. Furthermore, the vulnerability allows for the injection of arbitrary HTTP headers and bearer tokens into outbound requests. This capability facilitates credential theft from downstream services or enables session hijacking if valid authentication cookies or tokens are inadvertently included in the forged request context.
This flaw aligns with CWE-918, which classifies Server-Side Request Forgery (SSRF) as a weakness where an application retrieves data from a remote server specified by the user without sufficient validation of the destination address. The exploitation technique maps directly to MITRE ATT&CK T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer scenarios where compromised systems are used to access other internal resources. Additionally, it relates to CWE-200, Information Exposure, as the primary impact involves retrieving sensitive data from metadata services that should remain isolated from external network traffic. The severity is exacerbated by the lack of authentication requirements in default setups, making this a high-risk vulnerability for any deployment that does not explicitly enforce strict access controls on the API endpoints.
Mitigation strategies must focus on implementing robust input validation and enforcing secure defaults. Developers should apply the existing validate_url_not_private() logic to all URL parameters accepted from user input, ensuring that requests are blocked if they target private IP ranges, loopback addresses, or cloud metadata service IPs such as 169.254.169.254/32 and fd00:ec2::254/128. It is also critical to enforce authentication on the /v1/responses endpoint in production environments to prevent unauthenticated access entirely. Network-level controls, such as egress filtering or firewall rules that restrict outbound connections from application servers to only known trusted domains and IPs, provide an additional layer of defense against SSRF exploitation. Finally, removing sensitive headers like Authorization unless explicitly required by the specific tool definition can reduce the risk of credential leakage through forged requests.