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 Disagreement Over Severity
Wiz and LiteLLM's maintainers describe the guardrail code execution flaw, CVE-2026-59821, in almost incompatible terms.
Wiz calls it post-authentication code execution at root level and shows test output to support that. LiteLLM's own advisory rates it as Low severity, with a CVSS score of 2.1, noting that the flaw requires a high-privilege account. Both are describing the same behavior. What they disagree on is how to weigh the significance of that requirement, given that high-privilege access was readily available on nearly 10 percent of public instances.
LiteLLM's published security policy categorizes attacks that depend on setup mistakes, such as leaving the master key at its default value, as explicitly out of scope and not treated as vulnerabilities. The project's position is that operators who do not follow the setup instructions have created their own exposure. That is a reasonable position for a software maintainer to take. It is a harder position to defend when the setup guide's own example value is still `sk-1234` months after researchers flagged the issue.
The Flaw Attackers Have Actually Used
The code execution and cloud credential paths described above are Wiz demonstrations. Real attackers have been doing something related but distinct, using a different set of flaws against the same product.
CVE-2026-59822, a separate flaw also found by Wiz, lets an unauthenticated attacker establish a valid MCP session using any Bearer token, including a single character. The authentication handler for LiteLLM's MCP endpoint catches a 401 error from a failed token validation and silently returns an empty authentication object, granting access as if the request were valid. CISA added this to its Known Exploited Vulnerabilities catalog on September 2, with a CVSS score of 8.8. Federal civilian agencies had until September 16 to address it. Wiz's honeypots first recorded it being used in the wild on July 7, in requests probing model listing endpoints with single-character tokens. The agency designation makes it an urgent patch for government networks; the active exploitation makes it pressing for everyone else.
CVE-2026-42271, a different flaw with a CVSS score of 8.7, let any authenticated user run commands on the host through two MCP test endpoints. Horizon3.ai reported in June that it could be chained with a Starlette host-header validation bypass, CVE-2026-48710, to achieve unauthenticated remote code execution on vulnerable instances. Wiz's honeypots recorded attackers using that chain to drop an XMRig cryptocurrency miner via an ELF binary, after first fingerprinting the host and killing competing mining processes.
Microsoft published a case in August where attackers went further. After getting command execution inside a LiteLLM gateway process, they read the container's environment variables for the master key, provider keys, and database connection string. They then used the database string to connect to the PostgreSQL backend and copy records from LiteLLM's model and virtual-key tables. Microsoft assessed with high confidence that the entry point matched the CVE-2026-42271 and CVE-2026-48710 chain. "Treat AI gateways as Tier-0 secrets stores," the company said.
These active attacks sit on top of a separate incident from earlier this year. In March 2026, attackers used stolen maintainer credentials to publish two backdoored versions of LiteLLM to PyPI, versions 1.82.7 and 1.82.8. The malicious packages collected SSH keys, AWS, GCP, and Azure credentials, Kubernetes secrets, and database configurations from any environment that pulled them as a dependency. DSPy, MLflow, CrewAI, and OpenHands all pulled the compromised versions. A subsequent analysis by Hudson Rock found a 153-gigabyte stolen archive linked to the incident, containing files attributed to roughly 2,500 corporate domains including AWS, Samsung, Cisco, and Salesforce. The supply chain attack and the authentication flaws are separate incidents, but they affect the same product, and some organizations are managing fallout from both simultaneously.
What Needs to Happen
Every flaw in the Wiz report is patched in version 1.84.0 or later. The upgrade covers the MCP authentication bypass, the guardrail code execution flaw, the sandbox escape, and the endpoint that let non-admin accounts reach the pass-through configuration. There is no patch for the pass-through route to instance metadata, because LiteLLM does not treat it as a vulnerability. Restricting outbound network access from the container and scoping the workload's cloud IAM role as narrowly as possible are the only controls available for that path.
Changing the master key from `sk-1234` to a long random value requires no upgrade at all and closes every attack path in Wiz's report that depends on holding it. One check is worth doing before rotating: if a separate salt key is set in the configuration, the rotation procedure differs, and using the wrong one can leave stored credentials unreadable.
Organizations that cannot upgrade immediately should block the `/mcp/` path and the two MCP test endpoints at their reverse proxy or API gateway. Blocking `POST /guardrails/test_custom_code` and restricting the guardrail creation and update endpoints to administrators are the workarounds in LiteLLM's own advisories.
If there is any chance an attacker had access, the guardrails list should be reviewed for entries that were not created by the team, and the process should be restarted to clear code held in memory. Guardrails an attacker registered and SSH keys they may have added persist through an upgrade. The provider keys, master key, and database credentials should all be rotated.
The underlying issue is structural and not unique to LiteLLM. AI gateways now hold credentials for every model provider, execute server-side code, connect to internal tools through MCP, and run with the cloud permissions of the workloads they are deployed in. They have become critical infrastructure that is often still being treated as a developer convenience. The security controls surrounding them have not caught up.