CVE-2026-59823: LiteLLM SSRF — MEDIUM

Q: Is CVE-2026-59823 actively exploited?

No confirmed active exploitation of CVE-2026-59823 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-59823?

1) Upgrade litellm to 1.83.9 or later (fix in commit 47214be and PR #25827, advisory GHSA-hx8v-g79f-8w5f). 2) Until patched, apply egress filtering so the proxy can only reach approved LLM provider hosts, and block access to cloud metadata (169.254.169.254) and internal ranges; enforce IMDSv2 on AWS. 3) Add a WAF or API gateway rule rejecting request bodies containing user_config with api_base or base_url keys. 4) Audit and rotate virtual keys, remove unused ones, and apply least privilege. 5) Detection: log and alert on proxy requests containing a user_config field and on outbound connections from the proxy to unexpected or internal destinations. 6) Rotate provider API keys if suspicious outbound traffic is found.

Q: What systems are affected by CVE-2026-59823?

This vulnerability affects the following AI/ML architecture patterns: LLM gateways and proxies, Model serving, Multi-tenant LLM API platforms, Agent frameworks.

Q: What is the CVSS score for CVE-2026-59823?

No CVSS score has been assigned yet.

CISO Take

LiteLLM Proxy before 1.83.9 has a server-side request forgery flaw: an authenticated caller with a valid virtual key can hide an api_base inside the user_config request body, evading the check that blocks top-level api_base and base_url. The proxy then builds its outbound router from that value, so the caller can steer server-side requests to internal or external hosts, potentially reaching metadata services, internal APIs or admin endpoints they could not otherwise access. Exploitation likelihood is low to moderate (EPSS 0.44%, top 64%), there is no public exploit or Nuclei template, it is not in CISA KEV, and CISA SSVC says TRACK. The concern is that LiteLLM often sits as a central AI gateway holding provider credentials, and this package already has 44 other CVEs, so issued virtual keys (including those held by internal teams or contractors) become a pivot into the network. Upgrade to litellm 1.83.9 or later, and until then restrict egress from the proxy and review who holds virtual keys.

Sources:NVDEPSSGitHub AdvisoryATLASOpenSSFCISA SSVC

What is the risk?

Medium. Exploitation needs a valid virtual key (low privilege, network-reachable), but no user interaction and the request is trivial to craft once the bypass is known. EPSS is low (0.00439), there is no public exploit, no scanner template and no KEV listing. Impact depends on deployment: in cloud environments with reachable metadata endpoints or flat internal networks, SSRF can escalate to credential theft or internal service access. Package risk is elevated (score 79/100, 44 other CVEs, OpenSSF Scorecard 6.1/10), though only 6 known downstream dependents.

How does the attack unfold?

Initial Access

Attacker uses a valid LiteLLM virtual key to reach the proxy API.

AML.T0012

Exploitation

Attacker nests api_base inside user_config, bypassing is_request_body_safe, which checks only top-level fields.

AML.T0049

Internal Access

The proxy builds its outbound router from the nested destination and sends server-side requests to internal or attacker-chosen hosts.

Impact

Internal endpoints, metadata services or outbound credentials are exposed, enabling data leakage and lateral movement.

AML.T0055

Initial Access

Attacker uses a valid LiteLLM virtual key to reach the proxy API.

AML.T0012

Exploitation

Attacker nests api_base inside user_config, bypassing is_request_body_safe, which checks only top-level fields.

AML.T0049

Internal Access

The proxy builds its outbound router from the nested destination and sends server-side requests to internal or attacker-chosen hosts.

Impact

Internal endpoints, metadata services or outbound credentials are exposed, enabling data leakage and lateral movement.

AML.T0055

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	<= 1.83.8	`1.83.9`
62.5KOpenSSF 5.76 dependentsPushed 4d ago51% patched~47d to patchFull package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 38% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Upgrade litellm to 1.83.9 or later (fix in commit 47214be and PR #25827, advisory GHSA-hx8v-g79f-8w5f). 2) Until patched, apply egress filtering so the proxy can only reach approved LLM provider hosts, and block access to cloud metadata (169.254.169.254) and internal ranges; enforce IMDSv2 on AWS. 3) Add a WAF or API gateway rule rejecting request bodies containing user_config with api_base or base_url keys. 4) Audit and rotate virtual keys, remove unused ones, and apply least privilege. 5) Detection: log and alert on proxy requests containing a user_config field and on outbound connections from the proxy to unexpected or internal destinations. 6) Rotate provider API keys if suspicious outbound traffic is found.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

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

How is it classified?

Auth BypassData LeakageAPIFrameworkAML.T0012- Valid Accounts AML.T0049- Exploit Public-Facing Application AML.T0055- Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Responses to previously unknown risks

OWASP LLM Top 10

LLM03-Supply ChainLLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-59823?

LiteLLM Proxy before 1.83.9 has a server-side request forgery flaw: an authenticated caller with a valid virtual key can hide an api_base inside the user_config request body, evading the check that blocks top-level api_base and base_url. The proxy then builds its outbound router from that value, so the caller can steer server-side requests to internal or external hosts, potentially reaching metadata services, internal APIs or admin endpoints they could not otherwise access. Exploitation likelihood is low to moderate (EPSS 0.44%, top 64%), there is no public exploit or Nuclei template, it is not in CISA KEV, and CISA SSVC says TRACK. The concern is that LiteLLM often sits as a central AI gateway holding provider credentials, and this package already has 44 other CVEs, so issued virtual keys (including those held by internal teams or contractors) become a pivot into the network. Upgrade to litellm 1.83.9 or later, and until then restrict egress from the proxy and review who holds virtual keys.

Is CVE-2026-59823 actively exploited?

No confirmed active exploitation of CVE-2026-59823 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-59823?

1) Upgrade litellm to 1.83.9 or later (fix in commit 47214be and PR #25827, advisory GHSA-hx8v-g79f-8w5f). 2) Until patched, apply egress filtering so the proxy can only reach approved LLM provider hosts, and block access to cloud metadata (169.254.169.254) and internal ranges; enforce IMDSv2 on AWS. 3) Add a WAF or API gateway rule rejecting request bodies containing user_config with api_base or base_url keys. 4) Audit and rotate virtual keys, remove unused ones, and apply least privilege. 5) Detection: log and alert on proxy requests containing a user_config field and on outbound connections from the proxy to unexpected or internal destinations. 6) Rotate provider API keys if suspicious outbound traffic is found.

What systems are affected by CVE-2026-59823?

This vulnerability affects the following AI/ML architecture patterns: LLM gateways and proxies, Model serving, Multi-tenant LLM API platforms, Agent frameworks.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM gateways and proxiesModel servingMulti-tenant LLM API platformsAgent frameworks

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0049Exploit Public-Facing Application

AML.T0055Unsecured Credentials

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM03, LLM06

What are the technical details?

Original Advisory

LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.83.9, an authenticated LiteLLM Proxy caller with a valid virtual key can place api_base inside the user_config request body to bypass is_request_body_safe, which blocks top-level api_base and base_url but previously did not inspect or reject user_config. Because user_config constructs the outbound router, the nested destination redirects a server-side request to an internal or external host selected by the caller and can expose endpoints the caller cannot otherwise access. This issue is fixed in version 1.83.9.

Exploitation Scenario

An adversary with a legitimate low-privilege virtual key (for example a contractor or a compromised internal app key) sends a chat completion request to the LiteLLM Proxy with user_config containing an api_base pointing at an internal service or the cloud metadata endpoint. The is_request_body_safe check inspects only top-level fields and passes the request. The proxy builds a router from the nested destination and issues the server-side request, returning internal data or sending its outbound credentials to an attacker-controlled host. The attacker then uses the harvested credentials or internal reachability to move laterally.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery (SSRF)Primary 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.