As reported by The Hacker News, Wiz Research discovered that nearly one in ten internet-exposed LiteLLM AI gateways accepted sk-1234 — the literal placeholder from the project's own setup documentation. While the headline number is alarming, the deeper story is about how rapidly adopted AI infrastructure is repeating every mistake the cloud security community spent a decade correcting.
Why This Is Worse Than a Default Password
The LiteLLM master key is not a typical admin credential. It functions simultaneously as the authentication switch and the root administrative token. Before version 1.82.0-stable, a gateway that started without any master key configured simply granted unrestricted admin access to every incoming request — no credential required at all. Wiz found that 191 of the 294 vulnerable instances fell into this category, meaning the default key issue is actually the smaller half of the problem.
The core failure here isn't a software vulnerability — it's the absence of secure defaults in deployment architecture. When a product's documentation uses a placeholder credential and the software silently accepts its absence, you have a systemic design problem.
The Blast Radius Is Unusually Wide
An AI gateway sits in a uniquely privileged position in the stack. It holds API keys for every LLM provider the organization uses — OpenAI, Anthropic, Google, AWS Bedrock, and others. It sees every prompt and response in transit. It connects to internal systems via the Model Context Protocol. And it typically inherits the cloud IAM permissions of its host workload.
Wiz demonstrated that an admin can create a pass-through endpoint pointing at the cloud instance metadata service, exfiltrating IAM credentials. Critically, IMDSv2 does not prevent this because LiteLLM's x-pass- header forwarding mechanism allows attackers to inject the IMDSv2-required headers. This means the SSRF-to-cloud-credential chain works even on hardened instances.
Key Exposure Summary
| Asset Exposed | Impact |
|---|---|
| Provider API keys (OpenAI, Anthropic, etc.) | LLMjacking — unauthorized model usage billed to victim |
| All prompts and responses in transit | Data exfiltration, IP theft, compliance violations |
| MCP-connected internal tools | Lateral movement into enterprise systems |
| Cloud IAM credentials via SSRF | Full cloud account compromise depending on role scope |
Who Is Most at Risk
Organizations running LiteLLM with internet-facing deployments and default or missing master keys are at critical risk. The most exposed environments are:
Shield53 Recommendations
Immediate Actions
- Rotate the master key now. Set a cryptographically random value of at least 32 characters. This requires no software upgrade and closes every attack path Wiz described that depends on the default key.
- Upgrade to version 1.82.0-stable or later. This version enforces authentication when a master key is absent, closing the 191-instance vulnerability class where no key was set at all.
- Audit for exposed instances. Search your asset inventory for LiteLLM deployments. Check whether any are reachable from the internet. They should not be.
- Rotate all provider API keys if there is any chance your gateway was exposed. Assume compromise if the default key was in use on an internet-facing host.
- Review cloud IAM permissions on the workload running LiteLLM. Apply least privilege. If the gateway was exposed, rotate cloud credentials and check cloud audit logs for anomalous API calls.
Architectural Hardening
- Never expose LiteLLM directly to the internet. Place it behind a reverse proxy with TLS, WAF rules, and network ACLs. Restrict access to known application subnets only.
- Store secrets in a managed vault (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager) rather than environment variables or configuration files.
- Implement network segmentation so the gateway cannot reach the instance metadata service. Use network policies in Kubernetes or security groups in cloud environments to block traffic to
169.254.169.254. - Deploy IMDSv2 with hop count limits as defense in depth, though note this alone does not stop the LiteLLM pass-through SSRF chain.
- Monitor for pass-through endpoint creation. Treat any new pass-through route as a high-severity alert requiring review. Log the target URL and creating user.
Detection
If you cannot confirm your gateway was not exposed, treat the period from initial deployment to key rotation as potentially compromised. Check:
- LLM provider billing dashboards for unexpected usage spikes or new model access patterns
- Cloud trail / audit logs for IAM credential usage from unexpected IP ranges
- LiteLLM access logs for requests from unfamiliar source IPs or unusual admin operations
- Creation of pass-through endpoints targeting metadata addresses or internal services
The Bigger Picture
This incident illustrates a pattern we are seeing across the AI infrastructure ecosystem: open-source projects built for developer convenience are being deployed in production with the security posture of a local prototype. The LiteLLM documentation includes a comment telling operators to replace sk-1234 before real use — but as the data shows, a significant fraction of operators either missed or ignored that instruction.
Secure defaults matter more than documentation warnings. The fix that matters most is not the key rotation — it is the cultural shift where AI infrastructure gets the same security scrutiny applied to any other production system handling credentials and sensitive data. Until that happens, we will continue seeing AI gateways, vector databases, and model serving frameworks become the soft underbelly of enterprise security.
