LiteLLM Exposed Admin Key: What Wiz Research Found

A single default value, sk-1234, opened cloud access on hundreds of exposed AI gateways. This LiteLLM exposed admin key let Wiz Research walk into cloud credentials during a routine scan. Wiz Research scanned 3,074 internet-facing LiteLLM gateways in February. It found 294, nearly one in ten, either accepted the example key or lacked authentication entirely.

The LiteLLM master key does two jobs. It switches on authentication and also functions as the administrator credential. Leaving it unset could grant admin access, while sk-1234 exposed access to anyone who knew it. Wiz Research showed this access reaches beyond the gateway itself. Through pass-through routing, an admin can route to any URL, including a cloud metadata service. Wiz used this to retrieve live IAM credentials from the gateway’s host machine.

LiteLLM treats this path as intended, not a vulnerability, and has issued no CVE or fix. Its security policy separately lists setup mistakes, like an unset master key, as out of scope. Other LiteLLM CVEs exist independently of this issue, covered below.

How Wiz Research found the LiteLLM exposed admin key

Of the 3,074 LiteLLM gateways Wiz Research scanned in February 2026, 191 had no master key set at all, meaning they would accept any credential offered. The remaining 103 of the 294 exposed gateways still carried the example sk-1234 key straight from LiteLLM’s setup guide.

Wiz Research ran a second scan in August 2026 and found more than 85,000 LiteLLM instances, but most appeared to be honeypots or test systems. Wiz Research states the two scans do not allow a direct comparison, so there is no current figure for how many exposed gateways remain today. As of September 9, 2026, LiteLLM’s setup guide still lists sk-1234 as the example value, with a comment instructing operators to replace it with a long random value before real use.

One key, two jobs: Why the master key matters

The LiteLLM master key does two jobs at once. It switches on authentication, and it also works as the administrator credential itself. Before version 1.82.0-stable, a gateway that started without a configured master key granted full admin rights to every request it received.

An administrator’s access reaches far inside the gateway:

• It can read every provider’s API key stored on the server.
• It can see every prompt and response passing through.
• It can reach internal tools connected through the Model Context Protocol, or MCP.

The gateway typically runs with the cloud permissions of the workload hosting it. A stolen provider key alone lets an attacker run model workloads on the victim’s cloud bill, an abuse known as LLMjacking.

From admin access to cloud IAM credentials

LiteLLM lets an administrator create a pass-through endpoint, a route that forwards requests to any URL the admin chooses. Wiz Research showed how this feature reaches beyond the gateway itself:

• LiteLLM does not check the target URL against private address ranges, localhost, or cloud metadata addresses.
• An admin can point a pass-through route at the instance metadata service and read back live IAM credentials.
• Switching to IMDSv2 doesn’t block this path. IMDSv2 needs a session token via the X-aws-ec2-metadata-token header, but LiteLLM strips the x-pass- prefix from forwarded headers, so an admin sending x-pass-X-aws-ec2-metadata-token gets LiteLLM to deliver a valid token request on their behalf.

No public reporting confirms that anyone has used this path against a real deployment. Wiz Research demonstrated it as a proof of concept, and it requires admin access first. Wiz Research stated the feature is arguably working as intended, since LiteLLM’s threat model treats administrators as trusted. LiteLLM has issued no CVE and no fix for this path.

A disputed severity: The guardrail code execution flaws

Wiz Research and LiteLLM’s advisory describe one flaw very differently.

CVE-2026-59821 — endpoint check bypass:

• Involves the endpoints that create and update custom code guardrails.
• Before version 1.82.0-stable, these endpoints skipped the sandbox and pattern checks a separate test endpoint applied.
• Callers with a valid API key could submit Python code that ran inside the container.
• Wiz Research called it post-authentication root-level code execution, with testing that returned root access.
• LiteLLM’s advisory rates it Low, with a CVSS v4 score of 2.1.

CVE-2026-40217 — sandbox escape:

• A separate flaw that hits the sandbox itself, not the endpoints bypassing it.
• Published in May 2026, it describes a bytecode technique that escapes the guardrail sandbox.
• The escape runs code in the main proxy process, which runs as root in LiteLLM’s default Docker image.
• Covers versions 1.81.8 up to, but not including, 1.83.10.
• Exploiting it requires the master key.

LiteLLM fixed the flaws in February and April 2026; their CVEs were published separately.

A separate, actively exploited track

These issues are unrelated to the default-key and pass-through problems above, but they affect the same product.

CVE-2026-59822 (MCP bypass, CVSS 8.8):

CISA added it to the KEV catalog on September 2, 2026, with a September 16 deadline. It lets an unauthenticated attacker open an MCP session using any Bearer token, even one character long. Wiz Research saw it probe honeypots starting July 7, 2026; impact depends on connected tool servers.

CVE-2026-42271 (host command execution, CVSS 8.7):

Allows authenticated users to run host commands through two MCP test endpoints. Horizon3.ai reported in June 2026 that chaining it with the Starlette flaw CVE-2026-48710 enabled execution with no credentials.

Real-world impact:

Wiz Research saw CVE-2026-42271 used to install cryptocurrency miners on its honeypots. Microsoft documented an intrusion where attackers obtained the master key, provider keys, and database credentials from a gateway container. Microsoft assessed with high confidence that the entry point matched this chain, urging organizations to treat AI gateways as Tier-0 secret stores.

What’s Affected and What’s Fixed

Remediation checklist

• Rotate the master key from sk-1234 to a long, random value. This needs no upgrade, but check first whether a separate salt key exists, since rotation steps differ.
• Upgrade to LiteLLM 1.84.0 or later, which sits above the fixed version for every flaw in the table above.
• If an immediate upgrade is not possible, block the /mcp/ path and the two MCP test endpoints at your reverse proxy or API gateway.
• Block the custom-code guardrail test endpoint, and restrict guardrail creation and update endpoints to administrators only.
• Review every pass-through endpoint on the gateway, restrict its outbound network access, and assign the narrowest cloud IAM role the workload needs.
• If you suspect prior access, review the guardrails list for entries you did not create, restart the process to clear any code it holds in memory, and rotate the master key, provider keys, and database credentials.

Featured resource

The Cybersecurity Blueprint

Adopt the right cybersecurity strategy: key statistics, attack patterns, and step-by-step implementation guidance for your organization.

DOWNLOAD

Where Hexnode fits in this picture

This incident centers on a Linux-hosted gateway, and Microsoft’s documented intrusion took place inside a Linux Docker container. That puts it outside Hexnode’s current platform capabilities.

• Hexnode UEM manages device configuration, patch deployment, and compliance enforcement across endpoints. It does not manage application-level secrets or admin-panel settings on a server process like a LiteLLM gateway.
• Conditional Access via Microsoft Entra ID extends to Android, iOS, and macOS devices, gating resource access based on device compliance status. It does not extend to Linux server infrastructure.
• Hexnode IdP provides identity-based access control, RBAC, and MFA for approved apps. It doesn’t rotate an application’s own credentials or fix flaws like a default admin key on a self-hosted gateway.
• Hexnode XDR focuses on endpoint threat detection and response on Windows and macOS. It has no visibility into activity occurring inside a Linux-based gateway container.

None of these capabilities reach the actual failure point in this incident: a leaked application credential inside a Linux server process.

Conclusion

The LiteLLM exposed admin key shows how one overlooked setting turns an AI gateway into a path toward cloud credentials, provider API keys, and connected data. Treating that gateway as privileged identity infrastructure, not just another service, changes how you configure and monitor it.

Replacing default secrets, narrowing IAM roles and outbound access, and upgrading to a version resolving the known CVEs all reduce this exposure. None of these steps guarantee an attacker hasn’t already accessed a gateway exposed since February, so internet-facing LiteLLM operators should treat credential rotation and log review as immediate priorities.