CVE-2025-0330: LiteLLM Langfuse API key leak

Q: Is CVE-2025-0330 actively exploited?

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

Q: How to fix CVE-2025-0330?

1. PATCH: Upgrade LiteLLM beyond v1.52.1; verify fix is included in release notes before deploying. 2. ROTATE: Immediately rotate langfuse_secret and langfuse_public_key in all environments — assume any key configured in an affected version is compromised. 3. AUDIT: Review LiteLLM error logs and application logs for instances where team settings parsing failed; correlate timestamps with unauthorized Langfuse API activity. 4. SCOPE: Inventory all LiteLLM deployments across environments (dev/staging/prod); apply remediation consistently. 5. DETECT: Add alerting on Langfuse API key usage from unexpected IPs or at unusual times as a compensating control. 6. HARDEN: Ensure LiteLLM proxy error responses are not surfaced to end users or logged to external systems verbatim.

Q: What systems are affected by CVE-2025-0330?

This vulnerability affects the following AI/ML architecture patterns: LLM proxy and gateway deployments, AI observability and tracing pipelines, Multi-tenant LLM infrastructure, LLM inference infrastructure.

Q: What is the CVSS score for CVE-2025-0330?

CVE-2025-0330 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.52%.

CISO Take

LiteLLM proxy leaks Langfuse API credentials (secret and public keys) in error responses when team settings fail to parse — no authentication required to trigger. Any deployment of LiteLLM <= 1.52.1 with Langfuse integration is exposed: an attacker gains full access to your Langfuse project, including every LLM prompt and response ever logged. Upgrade immediately and rotate all Langfuse API keys; treat exposed keys as fully compromised.

What is the risk?

High risk for organizations running LiteLLM as an LLM gateway with Langfuse observability. CVSS 7.5 with network-accessible, zero-auth, zero-interaction vector makes this trivially exploitable. EPSS (0.00133) suggests limited active exploitation at time of disclosure, but LiteLLM is a widely deployed enterprise AI proxy, amplifying blast radius. The leaked credentials grant persistent read/write access to Langfuse — which stores the full history of LLM requests, potentially including PII, proprietary prompts, and internal tool outputs.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	<= 1.52.1	No patch
51.0K OpenSSF 6.1 6 dependents Pushed 3d ago 44% patched ~38d to patch Full package profile →

Do you use LiteLLM? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 40% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

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?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I None

A None

What should I do?

6 steps

PATCH

Upgrade LiteLLM beyond v1.52.1; verify fix is included in release notes before deploying.
ROTATE

Immediately rotate langfuse_secret and langfuse_public_key in all environments — assume any key configured in an affected version is compromised.
AUDIT

Review LiteLLM error logs and application logs for instances where team settings parsing failed; correlate timestamps with unauthorized Langfuse API activity.
SCOPE

Inventory all LiteLLM deployments across environments (dev/staging/prod); apply remediation consistently.
DETECT

Add alerting on Langfuse API key usage from unexpected IPs or at unusual times as a compensating control.
HARDEN

Ensure LiteLLM proxy error responses are not surfaced to end users or logged to external systems verbatim.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable Yes

Technical Impact partial

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

How is it classified?

Data Leakage Auth Bypass Data Extraction Framework API Inference AML.T0012 - Valid Accounts AML.T0025 - Exfiltration via Cyber Means AML.T0055 - Unsecured Credentials AML.T0083 - Credentials from AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.15 - Accuracy, Robustness and Cybersecurity

ISO 42001

A.10.1 - Information Security in AI System Lifecycle

NIST AI RMF

MANAGE-2.2 - Risk Treatment — Security of AI Systems

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2025-0330?

LiteLLM proxy leaks Langfuse API credentials (secret and public keys) in error responses when team settings fail to parse — no authentication required to trigger. Any deployment of LiteLLM <= 1.52.1 with Langfuse integration is exposed: an attacker gains full access to your Langfuse project, including every LLM prompt and response ever logged. Upgrade immediately and rotate all Langfuse API keys; treat exposed keys as fully compromised.

Is CVE-2025-0330 actively exploited?

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

How to fix CVE-2025-0330?

1. PATCH: Upgrade LiteLLM beyond v1.52.1; verify fix is included in release notes before deploying. 2. ROTATE: Immediately rotate langfuse_secret and langfuse_public_key in all environments — assume any key configured in an affected version is compromised. 3. AUDIT: Review LiteLLM error logs and application logs for instances where team settings parsing failed; correlate timestamps with unauthorized Langfuse API activity. 4. SCOPE: Inventory all LiteLLM deployments across environments (dev/staging/prod); apply remediation consistently. 5. DETECT: Add alerting on Langfuse API key usage from unexpected IPs or at unusual times as a compensating control. 6. HARDEN: Ensure LiteLLM proxy error responses are not surfaced to end users or logged to external systems verbatim.

What systems are affected by CVE-2025-0330?

This vulnerability affects the following AI/ML architecture patterns: LLM proxy and gateway deployments, AI observability and tracing pipelines, Multi-tenant LLM infrastructure, LLM inference infrastructure.

What is the CVSS score for CVE-2025-0330?

CVE-2025-0330 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.52%.

What is the AI security impact?

Affected AI Architectures

LLM proxy and gateway deploymentsAI observability and tracing pipelinesMulti-tenant LLM infrastructureLLM inference infrastructure

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Art.15

ISO 42001: A.10.1

NIST AI RMF: MANAGE-2.2

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

In berriai/litellm version v1.52.1, an issue in proxy_server.py causes the leakage of Langfuse API keys when an error occurs while parsing team settings. This vulnerability exposes sensitive information, including langfuse_secret and langfuse_public_key, which can provide full access to the Langfuse project storing all requests.

Exploitation Scenario

An adversary identifies a target organization running LiteLLM as their centralized AI gateway (e.g., via job postings mentioning LiteLLM, or open proxy endpoints). They craft an HTTP request to the LiteLLM proxy that triggers a team settings parsing error — this requires no credentials and can be done remotely. The resulting error response or log entry contains the raw langfuse_secret and langfuse_public_key in plaintext. The attacker uses these keys to authenticate directly to the Langfuse API, downloading the organization's full LLM interaction history: internal prompts revealing business logic, customer PII, RAG query content, and tool call parameters. With write access, they could also inject false traces to manipulate monitoring dashboards or corrupt evaluation baselines used for model governance.

Weaknesses (CWE)

CWE-1230 Exposure of Sensitive Information Through Metadata Primary

CWE-1230 — Exposure of Sensitive Information Through Metadata: The product prevents direct access to a resource containing sensitive information, but it does not sufficiently limit access to metadata that is derived from the original, sensitive information.

Source: MITRE CWE corpus.