CVE-2026-85666: Llama Stack SSRF — HIGH

CISO Take

OGX, the rebrand of Meta's Llama Stack, ships an OpenAI-compatible /v1/responses endpoint that lets a caller define an MCP tool with a server_url the server fetches on its own — and unlike other URL inputs in the codebase, this path skips the existing validate_url_not_private() guard entirely. Because the default starter configuration runs with no authentication and the flaw needs no privileges or user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N), any remote attacker who can reach the endpoint can point it at internal services or the cloud metadata endpoint (169.254.169.254) and have the server forward attacker-supplied headers and bearer tokens there — a direct path to cloud IAM credential theft. There's no EPSS score, KEV listing, public exploit, or Nuclei template yet, so this hasn't been weaponized at scale, but the combination of zero-auth default deployment and metadata-endpoint reach makes it trivially exploitable the moment it's found. Patch past the vulnerable state referenced at commit fbe8e0f (the vendor advisory covers v1.3.1) so server_url runs through validate_url_not_private(), and in the meantime never expose the default starter config to any network without authentication in front of it. Add egress controls on any host running OGX to block outbound requests to 169.254.169.254 and RFC1918 ranges, and monitor for unexpected outbound connections from the agent server to metadata or internal addresses.

Sources:NVDvulncheck.comgithub.comATLAS

What is the risk?

High risk despite the absence of confirmed in-the-wild exploitation. The exploit chain requires zero authentication, zero user interaction, and low attack complexity — an attacker only needs network reachability to the /v1/responses endpoint and knowledge of a target's internal topology or standard cloud metadata addresses. The default starter configuration ships without authentication, meaning any internet- or network-exposed default deployment is exploitable out of the box. Impact is scoped to confidentiality (C:H) via SSRF, but the specific ability to forward attacker-controlled headers and bearer tokens to attacker-chosen destinations turns this into a credential-theft primitive against cloud IAM roles, not just a generic blind SSRF. No EPSS percentile, CISA KEV listing, public PoC, or scanner template exists yet, which lowers near-term mass-exploitation likelihood but does not reduce severity for anyone running an exposed default instance today.

How does the attack unfold?

Initial Access

Attacker sends an unauthenticated request to the default starter configuration's /v1/responses endpoint.

AML.T0049

SSRF Exploitation

Attacker defines a malicious MCP tool with server_url pointing to an internal address or cloud metadata endpoint, bypassing the missing validate_url_not_private() check.

AML.T0053

Credential Harvesting

The server fetches the metadata endpoint and forwards attacker-supplied headers and bearer tokens, exposing cloud IAM credentials to the attacker.

AML.T0055

Impact

Attacker uses the stolen cloud credentials to pivot within the victim's cloud environment, accessing additional resources.

AML.T0091.000

Initial Access

Attacker sends an unauthenticated request to the default starter configuration's /v1/responses endpoint.

AML.T0049

SSRF Exploitation

Attacker defines a malicious MCP tool with server_url pointing to an internal address or cloud metadata endpoint, bypassing the missing validate_url_not_private() check.

AML.T0053

Credential Harvesting

The server fetches the metadata endpoint and forwards attacker-supplied headers and bearer tokens, exposing cloud IAM credentials to the attacker.

AML.T0055

Impact

Attacker uses the stolen cloud credentials to pivot within the victim's cloud environment, accessing additional resources.

AML.T0091.000

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Llama Stack	pip	—	No patch
8.4K14 dependentsPushed yesterday67% patched~0d to patchFull package profile →

Do you use Llama Stack? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.7%

chance of exploitation in 30 days

Higher than 54% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CHigh

INone

ANone

What should I do?

1 step

1) Upgrade OGX past the vulnerable state (commit fbe8e0f / advisory-referenced v1.3.1) to a release where server_url is routed through the existing validate_url_not_private() guard. 2) Never run the default starter configuration exposed to any untrusted network — require authentication in front of /v1/responses regardless of patch status, since defense-in-depth here is cheap and the blast radius (cloud credentials) is high. 3) Apply network egress controls on hosts running OGX/agent servers to block outbound traffic to 169.254.169.254 and RFC1918/link-local ranges unless explicitly required. 4) Enforce IMDSv2 with a low hop limit on cloud instances hosting this service to blunt SSRF-to-metadata even if the application-layer fix is delayed. 5) Detection: alert on outbound connections from the agent/inference host to metadata-service addresses or unexpected internal IP ranges, and audit MCP tool configuration submissions for server_url values pointing to private/link-local addresses.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Data LeakageAuth BypassAgentAPIPluginAML.T0049- Exploit Public-Facing Application AML.T0053- AI Agent Tool Invocation AML.T0055- Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

NIST AI RMF

MEASURE-2.7-AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-85666?

OGX, the rebrand of Meta's Llama Stack, ships an OpenAI-compatible /v1/responses endpoint that lets a caller define an MCP tool with a server_url the server fetches on its own — and unlike other URL inputs in the codebase, this path skips the existing validate_url_not_private() guard entirely. Because the default starter configuration runs with no authentication and the flaw needs no privileges or user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N), any remote attacker who can reach the endpoint can point it at internal services or the cloud metadata endpoint (169.254.169.254) and have the server forward attacker-supplied headers and bearer tokens there — a direct path to cloud IAM credential theft. There's no EPSS score, KEV listing, public exploit, or Nuclei template yet, so this hasn't been weaponized at scale, but the combination of zero-auth default deployment and metadata-endpoint reach makes it trivially exploitable the moment it's found. Patch past the vulnerable state referenced at commit fbe8e0f (the vendor advisory covers v1.3.1) so server_url runs through validate_url_not_private(), and in the meantime never expose the default starter config to any network without authentication in front of it. Add egress controls on any host running OGX to block outbound requests to 169.254.169.254 and RFC1918 ranges, and monitor for unexpected outbound connections from the agent server to metadata or internal addresses.

Is CVE-2026-85666 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-85666, increasing the risk of exploitation.

How to fix CVE-2026-85666?

1) Upgrade OGX past the vulnerable state (commit fbe8e0f / advisory-referenced v1.3.1) to a release where server_url is routed through the existing validate_url_not_private() guard. 2) Never run the default starter configuration exposed to any untrusted network — require authentication in front of /v1/responses regardless of patch status, since defense-in-depth here is cheap and the blast radius (cloud credentials) is high. 3) Apply network egress controls on hosts running OGX/agent servers to block outbound traffic to 169.254.169.254 and RFC1918/link-local ranges unless explicitly required. 4) Enforce IMDSv2 with a low hop limit on cloud instances hosting this service to blunt SSRF-to-metadata even if the application-layer fix is delayed. 5) Detection: alert on outbound connections from the agent/inference host to metadata-service addresses or unexpected internal IP ranges, and audit MCP tool configuration submissions for server_url values pointing to private/link-local addresses.

What systems are affected by CVE-2026-85666?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, model serving, MCP tool integrations.

What is the CVSS score for CVE-2026-85666?

CVE-2026-85666 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.73%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmodel servingMCP tool integrations

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0053AI Agent Tool Invocation

AML.T0055Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE-2.7

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker scans for internet-reachable OGX instances running the default starter configuration (no authentication required to reach /v1/responses). They submit a request defining an MCP tool whose server_url is set to http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>, along with attacker-controlled headers instructing the tool call to forward retrieved content to an attacker-controlled collection endpoint. The server, lacking the validate_url_not_private() check for this parameter, fetches the metadata service on the attacker's behalf and returns or forwards the temporary IAM credentials. The attacker then uses those stolen cloud credentials to pivot laterally within the victim's cloud account — enumerating S3 buckets, other compute instances, or secrets — turning an unauthenticated web request into a full cloud environment compromise.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.