LiteLLM Default Admin Key 'sk-1234' Exposed on 10% of Internet-Facing Gateways — Detection and Remediation Guide

In February 2026, Wiz Research scanned internet-facing LiteLLM servers and confirmed something that should concern every organization standing up AI infrastructure: nearly one in ten of the exposed gateways accepted sk-1234 — the example admin key printed in LiteLLM's own setup documentation — as a valid administrator credential.

This is not a memory corruption bug or a zero-day. It is something more uncomfortable: production AI gateways deployed with the tutorial's placeholder credential still in place, reachable from the public internet. Anyone holding that key can enumerate every virtual key on the gateway, read model configurations, inspect spend and usage data, potentially harvest downstream provider API keys (OpenAI, Anthropic, Azure, Bedrock), issue new credentials, and route unlimited inference through the victim's paid accounts. For an attacker, a compromised LiteLLM admin key is a skeleton key into an organization's entire LLM estate — and the data flowing through it.

If your team deployed LiteLLM following the quickstart guide and never rotated the master key, assume you are in the 10% until proven otherwise.

Technical Analysis

What LiteLLM Is and Why the Key Matters

LiteLLM is an open-source AI gateway/proxy that sits between internal applications and model providers. It normalizes API calls across providers, manages virtual keys for teams and applications, enforces budgets and rate limits, and logs requests and responses. The gateway is configured with a master key (typically set via the LITELLM_MASTER_KEY environment variable or the general_settings: master_key field in config.yaml) that functions as the administrative credential for the management API.

The setup documentation uses sk-1234 as the example value. A nontrivial slice of the internet copied it verbatim.

Attack Chain from a Defender's Perspective

1. Discovery: Attackers (and researchers) enumerate LiteLLM instances via Shodan/Censys fingerprints or by scanning for the default ports (commonly 4000) and characteristic endpoints such as /health/liveliness, /get/litellm_model_cost_map, or the /ui login page.
2. Authentication: The attacker presents Authorization: Bearer sk-1234 to any admin-scoped endpoint. On a misconfigured instance, the gateway accepts it because the master key was never changed from the example.
3. Exploitation of access: With master-key privileges, the attacker can call endpoints like /key/generate (mint new virtual keys), /key/info and /key/list (enumerate existing keys and associated teams/users), /model/info (list configured models), and critically the configuration endpoints that may expose the downstream provider API keys stored in the proxy config or environment. The attacker also inherits the ability to spend — running inference billed to the victim's provider accounts (financial denial of wallet).
4. Secondary impact: Because LiteLLM often proxies prompts and completions, a compromised gateway means potential exposure of sensitive data traversing the LLM pipeline — proprietary prompts, customer data, RAG-retrieved documents — plus a trusted pivot point inside the network.

Why This Keeps Happening

This is the AI-infrastructure version of the default-password problem that has plagued routers, databases, and CI/CD tools for decades. AI teams are moving fast, frequently deploying gateways from quickstart documentation into containers or VMs with broad network exposure, without a secrets-management step in between. The example credential is copied, the proxy works, the ticket is closed, and the gateway ships to production with a master key that is public knowledge.

There is no CVE associated with this finding — it is a deployment misconfiguration, not a vendor code flaw. Exploitation requires nothing more than an HTTP request. Treat it as actively exploited: any credential published in public documentation must be assumed to be in every scanner's wordlist.

Detection & Response

The highest-fidelity detection surface is the gateway's own request/audit logs and the network telemetry in front of it. Hunt for the literal string sk-1234 in authorization headers, and for anomalous admin-API usage patterns.

---
title: LiteLLM Default Example Master Key Usage
description: Detects HTTP requests presenting the LiteLLM documentation example key 'sk-1234' in an Authorization header, indicating the gateway master key was never rotated from the quickstart default. Tune to your proxy/WAF/Zeek log source.
references:
  - https://thehackernews.com/2026/09/nearly-1-in-10-exposed-litellm-gateways.html
author: Security Arsenal
date: 2026/09/08
id: 3f8c2a1e-7b41-4d9e-a6f2-9c1e5d8b2034
status: experimental
tags:
  - attack.initial_access
  - attack.t1078
logsource:
  category: webserver
detection:
  selection_header:
    cs-headers|contains: 'sk-1234'
  selection_field:
    Authorization|contains: 'sk-1234'
  condition: 1 of selection_*
falsepositives:
  - Internal testing against deliberately isolated dev instances (still investigate - the key must be rotated)
level: critical
---
title: LiteLLM Admin API Key Management Activity from External Source
description: Detects requests to LiteLLM administrative key-management endpoints (/key/generate, /key/list, /key/info) from non-internal source addresses, which may indicate an attacker abusing a compromised master key to mint or enumerate virtual keys.
references:
  - https://thehackernews.com/2026/09/nearly-1-in-10-exposed-litellm-gateways.html
author: Security Arsenal
date: 2026/09/08
id: 8d2e6b47-1c59-4a3d-bf80-5e7a2c9d1467
status: experimental
tags:
  - attack.credential_access
  - attack.t1552
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri-stem|contains:
      - '/key/generate'
      - '/key/list'
      - '/key/info'
      - '/user/new'
      - '/config/update'
  filter_internal:
    c-ip|startswith:
      - '10.'
      - '192.168.'
      - '172.16.'
  condition: selection_uri and not filter_internal
falsepositives:
  - Legitimate administration through a bastion or VPN that NATs to a public egress IP - baseline your admin paths
level: high

// Hunt for LiteLLM default key usage and admin API abuse in proxy/firewall/Syslog telemetry
// Assumes LiteLLM access logs or front-proxy logs are ingested into CommonSecurityLog or Syslog
let AdminPaths = dynamic(["/key/generate", "/key/list", "/key/info", "/user/new", "/config/update", "/model/info"]);
union isfuzzy=true
  (CommonSecurityLog
   | where TimeGenerated > ago(14d)
   | where RequestURL has_any (AdminPaths) or AdditionalExtensions has "sk-1234"
   | extend Indicator = iff(AdditionalExtensions has "sk-1234", "Default master key presented", "Admin endpoint accessed")
   | project TimeGenerated, SourceIP, DestinationIP, RequestURL, RequestMethod, Indicator, DeviceVendor, DeviceProduct),
  (Syslog
   | where TimeGenerated > ago(14d)
   | where SyslogMessage has "sk-1234" or SyslogMessage has_any (AdminPaths)
   | extend Indicator = iff(SyslogMessage has "sk-1234", "Default master key presented", "Admin endpoint accessed")
   | project TimeGenerated, HostIP, Computer, SyslogMessage, Indicator)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Hits = count() by SourceIP, RequestURL, Indicator
| order by Hits desc

-- Hunt for LiteLLM deployments still configured with the example master key
-- Checks running processes for LiteLLM proxy and config files for sk-1234
SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE CommandLine =~ 'litellm'
   OR Name =~ 'litellm'

-- Separately, sweep common config locations for the default key
SELECT FullPath, Size, Mtime, read_file(filename=FullPath) AS ConfigContent
FROM glob(globs=['/etc/litellm/**.yaml', '/opt/litellm/**.yaml', '/home/*/**/config.yaml', '/app/config.yaml', 'C:/Users/*/**/config.yaml'])
WHERE ConfigContent =~ 'sk-1234'

#!/bin/bash
# LiteLLM default master key audit and remediation helper
# Run on hosts running LiteLLM or via your config management pipeline
set -euo pipefail

FOUND=0

echo "=== [1/4] Scanning config files for the example master key ==="
CONFIG_PATHS=("/etc/litellm" "/opt/litellm" "/app" "$HOME")
for p in "${CONFIG_PATHS[@]}"; do
  [ -d "$p" ] || continue
  if grep -rIl 'sk-1234' "$p" 2>/dev/null; then
    echo "[!] FOUND 'sk-1234' in files under $p"
    FOUND=1
  fi
done

echo "=== [2/4] Checking environment variables of running LiteLLM processes ==="
for pid in $(pgrep -f litellm || true); do
  if tr '\0' '\n' < "/proc/$pid/environ" 2>/dev/null | grep -q 'LITELLM_MASTER_KEY=sk-1234'; then
    echo "[!] PID $pid has LITELLM_MASTER_KEY set to the default example key"
    FOUND=1
  fi
done

echo "=== [3/4] Checking Docker containers for the default key ==="
if command -v docker >/dev/null 2>&1; then
  for c in $(docker ps --format '{{.Names}}' 2>/dev/null | grep -i litellm || true); do
    if docker inspect "$c" --format '{{range .Config.Env}}{{println .}}{{end}}' | grep -q 'sk-1234'; then
      echo "[!] Container $c carries LITELLM_MASTER_KEY=sk-1234"
      FOUND=1
    fi
  done
fi

echo "=== [4/4] Verifying whether the gateway is internet-reachable ==="
ss -tlnp 2>/dev/null | grep -E ':(4000|8000)' || echo "No LiteLLM-typical ports bound locally"

if [ "$FOUND" -eq 1 ]; then
  echo ""
  echo "ACTION REQUIRED: Rotate the master key immediately:"
  echo "  1. Generate: openssl rand -hex 32"
  echo "  2. Set LITELLM_MASTER_KEY=sk-<new_value> via your secrets manager"
  echo "  3. Restart the gateway, then revoke/reissue all virtual keys (/key/delete + /key/generate)"
  echo "  4. Rotate any downstream provider keys stored in the config - assume compromise"
  echo "  5. Restrict admin endpoints to internal networks / VPN at the load balancer"
  exit 1
else
  echo "OK: No instance of the default key found on this host."
fi

Remediation

This is a configuration flaw, not a patchable CVE — remediation is entirely in your control and can be completed today.

1. Rotate the master key now. Generate a high-entropy replacement (openssl rand -hex 32), inject it through a secrets manager (Vault, AWS Secrets Manager, Azure Key Vault), and restart the gateway. Never reuse the documentation example or any human-memorable value.
2. Assume compromise if the gateway was internet-facing with the default key. Rotate all downstream provider API keys stored in the LiteLLM configuration, delete and reissue every virtual key, and review spend dashboards for unauthorized inference consumption.
3. Remove public exposure. An AI gateway has no business on the public internet in most architectures. Bind it to internal interfaces, place it behind an authenticated reverse proxy or VPN, and restrict admin endpoints (/key/*, /user/*, /config/*) to a management network via ACLs.
4. Enable and ship audit logging. Forward LiteLLM request logs to your SIEM and alert on the indicators in the detections above — especially any use of sk-1234 (which should hard-fail after rotation) and external hits to admin paths.
5. Audit for other copied defaults. The same teams that shipped sk-1234 likely deployed other AI stack components (vector DBs, model servers, orchestration dashboards) with documentation defaults. Extend the scan.
6. Institutionalize the fix. Add a CI/CD or pre-deployment check that fails any build containing documentation example credentials, and require secrets-manager injection for all gateway configuration.

The uncomfortable takeaway from the Wiz data is that AI infrastructure is repeating the operational-security mistakes of every technology wave before it — at machine speed. A gateway that brokers access to your models, your provider credentials, and your prompt data is a tier-zero asset. Treat its admin credential accordingly.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub