EUVD-2026-96884
GHSA-wxjw-vcvf-mvw9
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain valid low-privilege API key
-
DeliveryCall ui_view_session_spend_logs endpoint
-
ExploitSubstitute another tenant's session_id
-
ExecutionBypass authorization check (CWE-639)
-
ImpactRead unauthorized spend logs
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Object-level authorization, IDOR prevention
|
| Exploitation Conditions | Exploitation requires the attacker to already hold a valid low-privilege LiteLLM credential (PR:L) that can reach the Spend Tracking UI endpoint ui_view_session_spend_logs; it is a user-controlled-key IDOR where the attacker supplies another party's session_id to retrieve that session's spend logs. Limiting factors: authentication is mandatory (no anonymous access), the impact is confined to reading spend/usage data (confidentiality only - no modification or service disruption), and real-world risk is materially higher only in multi-tenant deployments where separate users or teams share one proxy and tenant isolation matters. Single-tenant or trusted-internal LiteLLM proxies face minimal practical exposure. Affected versions are BerriAI LiteLLM up to and including 1.95.0; upgrading to 1.96.0 removes the flaw. |
| Impact | This is a moderate, real-but-not-urgent issue. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) and score of 5.3 describe a network-reachable, low-complexity authorization bypass (IDOR, CWE-639) that still requires an authenticated low-privilege caller (PR:L) and yields only low confidentiality impact with no integrity or availability effect. The vendor-supplied vector includes E:P (proof-of-concept), consistent with the description stating the exploit has been published, so publicly available exploit code exists. However, the vulnerability is NOT in CISA KEV and no EPSS score was provided in the input, so there is no evidence of active, widespread exploitation - the signals point to opportunistic abuse by an already-authenticated tenant rather than mass internet exploitation. The PR:L requirement meaningfully reduces priority versus an unauthenticated flaw. One caveat to verify: the description names the vulnerable function ui_view_session_spend_logs manipulating session_id, but the provided patch diff primarily adds hardened /spend/report scope-resolution helpers (_resolve_spend_report_scope) and parameterized SQL - the diff excerpt does not directly display the ui_view_session_spend_logs fix, so the exact code path should be confirmed against the full commit. Overall: a legitimate priority for multi-tenant LiteLLM proxy operators where tenant data isolation matters, but low-to-medium priority for single-tenant or internal-only deployments. |
| Exploit ScenarioDerived | An authenticated low-privilege LiteLLM user holding a valid but limited API key calls the spend-tracking UI endpoint and substitutes another tenant's session_id, causing the proxy to return spend logs belonging to a session the caller is not authorized to view. Because published exploit code exists and the attack is remote with low complexity, a malicious tenant can iterate session_id values to harvest other users' usage and cost data. No user interaction or elevated privileges are needed beyond holding any valid key. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 11, 2026
An authenticated authorization bypass (IDOR) in BerriAI LiteLLM up to and including 1.95.0 allows a low-privileged user holding any valid proxy API key to read spend and usage logs belonging to other users, keys, or teams by supplying a foreign session_id to the Spend Tracking UI endpoint ui_view_session_spend_logs. Exploitation requires a valid credential (CVSS PR:L) but no user interaction, and the impact is limited to confidentiality - an attacker can view another tenant's token counts and cost data but cannot modify records or disrupt service. Publicly available exploit code exists (the CVSS 4.0 vector carries E:P and VulDB reports a published exploit), but there is no confirmed active exploitation (CISA KEV); the realistic risk is materially higher in multi-tenant or shared-proxy deployments where tenant isolation matters, and low in single-tenant or trusted-internal installations. Vendor-released patch: v1.96.0.
RemediationAI
Upgrade to BerriAI LiteLLM 1.96.0, the vendor-released patch that resolves this issue; the corresponding source fix is commit 722d9ffa4f6c5ae15702ab9ab2c5f6bf1688308b and the release is published at https://github.com/BerriAI/litellm/releases/tag/v1.96.0 (advisory context at https://vuldb.com/vuln/416231). Until the upgrade can be staged, the most effective compensating control is to remove the attack surface: restrict network access to the LiteLLM proxy's Spend Tracking UI and management routes so that only trusted administrative networks or an authenticating reverse proxy can reach them, accepting the trade-off that legitimate tenants lose self-service spend visibility. If per-tenant spend viewing is required, front the proxy with a layer that enforces object-level authorization on session_id - or issue strictly scoped API keys per tenant and segregate high-value tenants onto separate proxy instances/databases - though this adds operational overhead and does not fix the underlying IDOR. Because the endpoint is gated to premium_user == True, non-enterprise deployments can also reduce exposure by confirming the feature is not enabled, and administrators should audit LiteLLM_SpendLogs access logs for requests enumerating session_id values that do not belong to the requesting key as a detection and scoping measure. Rotating or restricting the low-privilege keys that can reach this endpoint limits an attacker's ability to trigger the flaw, since authentication is mandatory for exploitation.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is a classic CWE-639 authorization bypass through a user-controlled key, rooted in the Spend Tracking subsystem of the LiteLLM proxy (litellm/proxy/spend_tracking/spend_management_endpoints.py). The endpoint ui_view_session_spend_logs accepts a caller-supplied session_id and uses it to look up spend records without confirming that the requesting principal is entitled to that session, so the identifier itself effectively becomes an authorization token. LiteLLM is an OpenAI-compatible LLM gateway/proxy that centralizes API keys, teams, organizations, and per-request cost accounting, and its spend-tracking tables (LiteLLM_SpendLogs) aggregate cost, prompt-token, and completion-token data - information that in a multi-tenant deployment is sensitive from a business and capacity-planning standpoint. The patch commit 722d9ffa4f6c5ae15702ab9ab2c5f6bf1688308b is instructive: it adds the /key, /user, /team, and /organization spend-report routes to LiteLLMRoutes and introduces hardened helpers - a _SPEND_REPORT_SCOPE_COLUMNS allowlist that forbids interpolating caller input into SQL scope columns, parameter-bound scope values ($3), and a _resolve_spend_report_scope() routine that derives the permissible scope from the authenticated user_api_key_dict rather than trusting the request. That code evidence confirms the root cause is a missing ownership/scope check on a client-supplied identifier rather than a memory-safety or injection defect. The same code shows these spend-report endpoints are gated behind a premium_user == True check, meaning the affected functionality is primarily present in enterprise/paid LiteLLM deployments.
Know when Litellm gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:P
Remote, low-complexity IDOR requiring any valid low-privilege key (PR:L, AV:N, AC:L); leaks only spend-log data so C:L with I:N/A:N and unchanged scope.
Primary rating from Vendor (VulDB).
CVSS VectorVendor: VulDB
Lifecycle Timeline
2DescriptionCVE.org
A flaw has been found in BerriAI LiteLLM up to 1.95.0. Affected by this issue is the function ui_view_session_spend_logs of the file litellm/proxy/spend_tracking/spend_management_endpoints.py of the component Spend Tracking. Executing a manipulation of the argument session_id can lead to authorization bypass. It is possible to launch the attack remotely. The exploit has been published and may be used. Upgrading to version 1.96.0 can resolve this issue. This patch is called 722d9ffa4f6c5ae15702ab9ab2c5f6bf1688308b. The affected component should be upgraded.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Remote command execution in LiteLLM proxy server versions 1.74.2 through 1.83.6 allows any authenticated user to execute
SQL injection in LiteLLM proxy server versions 1.81.16 through 1.83.6 allows unauthenticated remote attackers to read an
Authentication bypass in LiteLLM (BerriAI) proxy/AI Gateway before 1.84.0 lets a remote unauthenticated attacker reach M
BerriAI/litellm is vulnerable to Server-Side Template Injection (SSTI) via the `/completions` endpoint. Rated critical s
Remote code execution in BerriAI LiteLLM (all versions through 2026-04-08) enables authenticated attackers to execute ar
BerriAI's litellm, in its latest version, is vulnerable to arbitrary file deletion due to improper input validation on t
Authentication bypass in the LiteLLM proxy lets any party who already holds a valid JWT issued by the configured externa
In berriai/litellm version v1.52.1, an issue in proxy_server.py causes the leakage of Langfuse API keys when an error oc
In berriai/litellm before version 1.44.12, the `litellm/litellm_core_utils/litellm_logging.py` file contains a vulnerabi
A Server-Side Request Forgery (SSRF) vulnerability exists in berriai/litellm version 1.38.10. Rated high severity (CVSS
An SQL Injection vulnerability exists in the berriai/litellm repository, specifically within the `/global/spend/logs` en
A code injection vulnerability exists in the berriai/litellm application, version 1.34.6, due to the use of unvalidated
Exploit-DB