Security researchers at Wiz scanned 3,074 internet-facing deployments of LiteLLM in February and found something that should embarrass more than a few engineering teams: 294 of them, just under 10 percent, accepted `sk-1234` as the administrator password. That is the exact value printed in LiteLLM's own quickstart guide, sitting above a comment telling operators to replace it with a long random value before any real use. As of September 9, the guide still reads that way.
The number sounds like a configuration slip, the kind that shows up in enterprise audits and gets quietly fixed. The consequences here are anything but quiet. LiteLLM sits between a company's applications and every AI provider it pays for. Whoever holds the master key can read every provider API key stored on the server, inspect every prompt and reply that moves through it, reach internal tools connected via the Model Context Protocol, and, as Wiz demonstrated, pull the cloud IAM credentials off the machine the gateway runs on. Researchers also found a code execution path that returned root access inside the container during testing. Attackers have since been seen using related flaws to install cryptocurrency miners and copy entire databases of provider credentials.
What LiteLLM Actually Is, and Why It Matters
LiteLLM is an open-source AI gateway. Companies use it as a single routing layer for more than 100 model providers, including OpenAI, Anthropic, AWS Bedrock, Azure, and Google Vertex AI. Rather than scattering API keys and budgets across every team and application, organizations push all their inference traffic through one place. That makes LiteLLM a centralized store for some of the most valuable secrets in a modern cloud environment.
According to Wiz's own cloud data, roughly one in three cloud environments already has a LiteLLM deployment. The project has more than 22,000 stars on GitHub. Many of those instances sit behind corporate networks and VPNs, unreachable from the internet. But the 3,074 Wiz found on Shodan in February were not.
The master key does two things at once, which is what makes a default value particularly dangerous here. It is the administrator credential for the proxy. It is also the secret LiteLLM uses to sign session JWTs with HS256. When it stays at `sk-1234`, anyone who knows that can forge arbitrary user sessions for the entire proxy without ever brute-forcing a password. They just already know it because they read the docs.
Of the 294 instances that accepted the default key, 191 had no master key set at all, meaning the server accepted any request. Before version 1.82.0-stable, gateways with no master key granted every incoming request full proxy administrator rights automatically, no credential needed.
How Far an Attacker Gets
Wiz researchers, working through LiteLLM's codebase with Claude Code, traced what an administrator credential actually unlocks beyond the obvious credential theft.
LiteLLM has a pass-through endpoint feature that lets administrators create proxy routes forwarding requests to any URL they choose. The target URL is never checked against private address ranges, localhost, or cloud metadata addresses. A researcher can point a route at the AWS instance metadata service and read back IAM credentials in a straightforward request chain. The feature works the same way against IMDSv2, which is supposed to require a specific token header to prevent exactly this kind of request. LiteLLM's header forwarding mechanism passes any header prefixed with `x-pass-` to the target with the prefix removed, so an attacker can send the IMDSv2 token request headers along for the ride.
Wiz describes this as arguably working as intended. LiteLLM's threat model treats administrators as trusted, and the project has not assigned it a CVE or issued a fix. The problem, as the researchers put it, is that the threat model has often been broken by deployments that never changed the default key.
The code execution path is a separate issue. LiteLLM lets administrators register custom Python guardrails, code that runs around every inference request to enforce policies like blocking sensitive prompts or filtering outputs. Before version 1.82.0-stable, the endpoint that registers a guardrail applied none of the safety checks present in the test interface. The test interface blocks `import`, `os`, `subprocess`, and strips Python's built-in functions before execution. The registration endpoint did neither. Submitted code ran with the full standard library, inside the container, at root, immediately on registration. Wiz showed this with a proof of concept returning `uid=0(root) gid=0(root)` in the guardrail's block reason field after a single chat completion call.
A second flaw, CVE-2026-40217, published in May, showed that even after the guardrail sandbox was added in 1.82.0, it could be escaped using Python bytecode techniques. That one affects versions 1.81.8 through 1.83.10. The same admin credential is the entry point for both.
The
[…]
Content was trimmed to protect the source. Please visit the original article for the full text.
Read the original article: