CVE-2026-84377: LiteLLM param injection leaks

Q: Is CVE-2026-84377 actively exploited?

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

Q: How to fix CVE-2026-84377?

Upgrade LiteLLM to 1.88.6 (if on the 1.88.x line) or 1.96.2 (if on a later line) immediately — these versions fix the incomplete validation in auth_utils.py, common_request_processing.py, _health_endpoints.py, image endpoints, and litellm_pre_call_utils.py. As an immediate compensating control before patching, restrict which users/roles can set api_base, base_url, model_list, fallbacks, and litellm_credential_name at request time, and enforce an egress allowlist so the proxy host can only reach known provider domains and internal services it legitimately needs. After patching, rotate all provider API keys configured in the LiteLLM proxy as a precaution against undetected prior abuse. For detection, review proxy egress logs and any outbound-request audit trail for calls to unexpected/unknown destination hosts or IPs, especially non-provider domains, correlated with authenticated low-privilege accounts.

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

This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks, RAG pipelines.

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

CVE-2026-84377 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.54%.

CISO Take

LiteLLM's proxy (AI Gateway) used incomplete request validation across five endpoint handlers, so any authenticated user, even a low-privileged one, could redirect an outbound LLM provider call to a destination they control by setting parameters like api_base, base_url, model_list, fallbacks, or litellm_credential_name, while the proxy still attached its configured provider credentials to the request. The gap missed nested fields, path values, and bracket-notation form data, making this a systemic validation weakness rather than a single overlooked field, and it affects any organization centralizing OpenAI, Anthropic, Azure, or other provider keys behind LiteLLM (6 known downstream dependents, package risk score 79/100, 41 other CVEs in this package). There is no CISA KEV listing, no public exploit or Nuclei template, and EPSS data is not yet available, and exploitation requires an authenticated low-privilege account (PR:L), so this is not an unauthenticated internet-wide threat, but it is trivially reproducible by any onboarded user, service account, or insider and enables both credential theft and SSRF against internal services reachable by the proxy. Patch to 1.88.6 or 1.96.2 immediately, rotate all provider credentials configured in the proxy as a precaution, and audit proxy egress logs for outbound calls to unexpected hosts.

Sources:NVDGitHub AdvisoryATLASOpenSSF

What is the risk?

Medium severity per CVSS (6.5, confidentiality-only impact) but the practical risk for AI-heavy organizations is elevated by exposure and blast radius: the vulnerability requires only low privileges and no user interaction, is network-exploitable, and directly targets the credential store that makes a centralized LLM gateway valuable in the first place. Because LiteLLM sits between many internal consumers and one set of provider keys, a single malicious or compromised low-privileged account can escalate to full provider-credential theft and internal network reconnaissance via SSRF (CWE-918), without needing to compromise the underlying infrastructure. No active exploitation (not in CISA KEV), no public PoC, and no EPSS score are currently available, which lowers near-term opportunistic risk but does not reduce insider or lateral-movement risk once an attacker has any valid low-privilege account.

How does the attack unfold?

Initial Access

Attacker obtains or already controls a low-privileged, authenticated account on the LiteLLM proxy (e.g., a scoped API key or compromised service account).

AML.T0012

Parameter Injection

Attacker crafts a request setting api_base, base_url, model_list, fallbacks, or litellm_credential_name via nested fields, path values, or bracket-notation form data that bypass the proxy's incomplete validation.

Credential Exfiltration

The proxy forwards the outbound provider call, including its stored operator API key/secrets, to the attacker-controlled destination instead of the legitimate provider.

AML.T0055

Impact

Attacker gains valid upstream provider credentials for unauthorized use and can repeat the technique to reach internal services behind the proxy via SSRF.

AML.T0025

Initial Access

Attacker obtains or already controls a low-privileged, authenticated account on the LiteLLM proxy (e.g., a scoped API key or compromised service account).

AML.T0012

Parameter Injection

Attacker crafts a request setting api_base, base_url, model_list, fallbacks, or litellm_credential_name via nested fields, path values, or bracket-notation form data that bypass the proxy's incomplete validation.

Credential Exfiltration

The proxy forwards the outbound provider call, including its stored operator API key/secrets, to the attacker-controlled destination instead of the legitimate provider.

AML.T0055

Impact

Attacker gains valid upstream provider credentials for unauthorized use and can repeat the technique to reach internal services behind the proxy via SSRF.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	< 1.88.6	`1.88.6`
62.5KOpenSSF 5.76 dependentsPushed yesterday51% patched~47d to patchFull package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

6.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 45% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACLow

PRLow

UINone

SUnchanged

CHigh

INone

ANone

What should I do?

1 step

Upgrade LiteLLM to 1.88.6 (if on the 1.88.x line) or 1.96.2 (if on a later line) immediately — these versions fix the incomplete validation in auth_utils.py, common_request_processing.py, _health_endpoints.py, image endpoints, and litellm_pre_call_utils.py. As an immediate compensating control before patching, restrict which users/roles can set api_base, base_url, model_list, fallbacks, and litellm_credential_name at request time, and enforce an egress allowlist so the proxy host can only reach known provider domains and internal services it legitimately needs. After patching, rotate all provider API keys configured in the LiteLLM proxy as a precaution against undetected prior abuse. For detection, review proxy egress logs and any outbound-request audit trail for calls to unexpected/unknown destination hosts or IPs, especially non-provider domains, correlated with authenticated low-privilege accounts.

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?

Data LeakageAuth BypassAPIInferenceAML.T0012- Valid Accounts AML.T0025- Exfiltration via Cyber Means AML.T0055- Unsecured Credentials

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2-AI system operation and monitoring / resource security

OWASP LLM Top 10

LLM02-Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-84377?

LiteLLM's proxy (AI Gateway) used incomplete request validation across five endpoint handlers, so any authenticated user, even a low-privileged one, could redirect an outbound LLM provider call to a destination they control by setting parameters like api_base, base_url, model_list, fallbacks, or litellm_credential_name, while the proxy still attached its configured provider credentials to the request. The gap missed nested fields, path values, and bracket-notation form data, making this a systemic validation weakness rather than a single overlooked field, and it affects any organization centralizing OpenAI, Anthropic, Azure, or other provider keys behind LiteLLM (6 known downstream dependents, package risk score 79/100, 41 other CVEs in this package). There is no CISA KEV listing, no public exploit or Nuclei template, and EPSS data is not yet available, and exploitation requires an authenticated low-privilege account (PR:L), so this is not an unauthenticated internet-wide threat, but it is trivially reproducible by any onboarded user, service account, or insider and enables both credential theft and SSRF against internal services reachable by the proxy. Patch to 1.88.6 or 1.96.2 immediately, rotate all provider credentials configured in the proxy as a precaution, and audit proxy egress logs for outbound calls to unexpected hosts.

Is CVE-2026-84377 actively exploited?

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

How to fix CVE-2026-84377?

Upgrade LiteLLM to 1.88.6 (if on the 1.88.x line) or 1.96.2 (if on a later line) immediately — these versions fix the incomplete validation in auth_utils.py, common_request_processing.py, _health_endpoints.py, image endpoints, and litellm_pre_call_utils.py. As an immediate compensating control before patching, restrict which users/roles can set api_base, base_url, model_list, fallbacks, and litellm_credential_name at request time, and enforce an egress allowlist so the proxy host can only reach known provider domains and internal services it legitimately needs. After patching, rotate all provider API keys configured in the LiteLLM proxy as a precaution against undetected prior abuse. For detection, review proxy egress logs and any outbound-request audit trail for calls to unexpected/unknown destination hosts or IPs, especially non-provider domains, correlated with authenticated low-privilege accounts.

What systems are affected by CVE-2026-84377?

This vulnerability affects the following AI/ML architecture patterns: model serving, agent frameworks, RAG pipelines.

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

CVE-2026-84377 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.54%.

What is the AI security impact?

Affected AI Architectures

model servingagent frameworksRAG pipelines

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0025Exfiltration via Cyber Means

AML.T0055Unsecured Credentials

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

OWASP LLM Top 10: LLM02

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 versions 1.88.6 and 1.96.2, any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination the user controls and cause the proxy to send its configured provider credentials to that destination. Request validation in litellm/proxy/auth/auth_utils.py, litellm/proxy/common_request_processing.py, litellm/proxy/health_endpoints/_health_endpoints.py, litellm/proxy/image_endpoints/endpoints.py, and litellm/proxy/litellm_pre_call_utils.py used incomplete checks that did not cover every sensitive parameter or inspect equivalent values across nested request fields, path values, and bracket-notation form data. Routing and credential parameters including api_base, base_url, model_list, fallbacks, and litellm_credential_name could therefore be applied without clearing the operator's stored key, exposing upstream provider credentials and other configured secrets and permitting server-side requests to internal services reachable by the proxy. This issue is fixed in versions 1.88.6 and 1.96.2.

Exploitation Scenario

An attacker obtains or already holds a low-privileged, authenticated account on an organization's LiteLLM proxy (e.g., a developer test key, a service account for one internal app, or a compromised low-priv credential). They send a normal-looking completion or health-check request but inject a routing/credential override — for example setting api_base or litellm_credential_name via a nested JSON field, a URL path segment, or bracket-notation form data that the validation logic didn't inspect — pointing the outbound call at an attacker-controlled HTTP listener. Because the incomplete checks didn't clear the operator's stored key when these fields were set, the proxy forwards the request to the attacker's server complete with the organization's real provider API key (and potentially other configured secrets) in the headers or body. The attacker now holds valid upstream provider credentials for unauthorized use (cost abuse, data access via the provider API) and can repeat the technique with internal IPs/hostnames to probe or reach services behind the proxy that were never meant to be internet- or user-reachable.

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.