Full Report
Nearly one in ten of the internet-facing LiteLLM servers that Wiz Research scanned in February accepted sk-1234, the example admin key in LiteLLM's own setup guide. LiteLLM is an open-source AI gateway, the software a company puts between its applications and the model providers it pays for. That key is the gateway's administrator credential. Anyone who holds it can read every
Analysis Summary
# Incident Report: Exposure of LiteLLM Gateways via Default Administrative Credentials
## Executive Summary
Wiz Research discovered that approximately 10% of internet-facing LiteLLM AI gateways were accessible using the default "sk-1234" admin key or had no authentication enabled at all. This misconfiguration allows attackers to hijack AI API keys, intercept sensitive model communications, and escalate privileges to the underlying cloud infrastructure. While LiteLLM has introduced sandboxing and security advisories, the core issue stems from users failing to replace example credentials provided in the setup documentation.
## Incident Details
- **Discovery Date:** February 2026 (Initial Scan); August 2026 (Follow-up)
- **Incident Date:** Ongoing/Active
- **Affected Organization:** Multiple (3,074 servers identified in Feb; 85,000+ instances in Aug)
- **Sector:** Technology / Artificial Intelligence / Various
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** February 2026 (Wiz Scan)
- **Vector:** Default Credential Exploitation / Authentication Bypass
- **Details:** Attackers (or researchers) used the example admin key `sk-1234` from the LiteLLM documentation to gain full administrative access. In some cases, gateways were deployed with no key, granting full rights by default.
### Lateral Movement
- **Cloud Metadata Access:** Using administrative access, researchers created pass-through endpoints pointing to the Instance Metadata Service (IMDS).
- **Credential Theft:** By prepending headers with `x-pass-`, researchers bypassed IMDSv2 protections to retrieve cloud IAM credentials of the host machine.
### Data Exfiltration/Impact
- **LLMjacking:** Access to model provider API keys (OpenAI, Anthropic, etc.) allows unauthorized use of model workloads on the victim's bill.
- **Data Interception:** Ability to view all prompts and replies (PII/Secret leakage) passing through the gateway.
- **RCE:** Exploitation of custom code guardrails (CVE-2026-59821) allowed Python execution within the container.
### Detection & Response
- **Discovery:** Identified by Wiz Research via Shodan scanning.
- **Response Actions:** LiteLLM issued version 1.82.0-stable to ensure gateways without a key do not default to admin rights; introduced sandboxing for custom code.
## Attack Methodology
- **Initial Access:** Default Credentials (`sk-1234`) or Absence of Authentication.
- **Persistence:** Creation of administrative API keys or pass-through endpoints.
- **Privilege Escalation:** Use of Model Context Protocol (MCP) and pass-through endpoints to target cloud metadata services.
- **Defense Evasion:** Use of `x-pass-` header prefixes to manipulate headers sent to internal services.
- **Credential Access:** Extraction of stored model provider keys and host IAM credentials.
- **Discovery:** Shodan scanning for LiteLLM signatures.
- **Impact:** Financial loss via LLMjacking; full compromise of AI data flows.
## Impact Assessment
- **Financial:** High potential for unauthorized cloud/LLM billing (LLMjacking).
- **Data Breach:** Exposure of all AI-processed data, prompts, and third-party API keys.
- **Operational:** Potential for root-level container compromise.
- **Reputational:** High, due to the use of well-documented example keys in production.
## Indicators of Compromise
- **Behavioral indicators:**
- Requests using the admin key `sk-1234`.
- Creation of new pass-through endpoints targeting `169.254.169.254` or `localhost`.
- Unusual `x-pass-` headers in gateway logs.
## Response Actions
- **Containment:** Organizations must immediately change the `MASTER_KEY` environment variable.
- **Eradication:** Update LiteLLM to version 1.82.0-stable or higher to enforce authentication defaults.
- **Recovery:** Rotate all model provider API keys and cloud IAM credentials associated with the LiteLLM host.
## Lessons Learned
- **Documentation Risk:** Example keys in setup guides (like `sk-1234`) are frequently copy-pasted into production by users.
- **Default Insecurity:** Software should fail-secure (refuse to start) if a secure key is not provided, rather than defaulting to "no authentication."
- **Feature Misuse:** Pass-through functionality without SSRF (Server-Side Request Forgery) protections can lead to total cloud compromise.
## Recommendations
- **Rotate Credentials:** Immediately replace default admin keys with high-entropy random strings.
- **Network Isolation:** Restrict access to the LiteLLM admin dashboard/API to specific internal IP ranges or VPNs.
- **Metadata Protection:** Ensure the host environment restricts access to the metadata service (IMDS) from the container runtime.
- **Monitoring:** Set up alerts for any configuration changes or model usage spikes that deviate from historical norms.