In February, Wiz Research discovered that nearly 10% of LiteLLM servers accessible from the internet accepted an example admin key, sk-1234. This key, included in LiteLLM’s setup guide, serves as a gateway administrator credential, allowing access to sensitive data stored on the server. Anyone possessing this key can potentially read API keys and cloud IAM credentials on the host machine.
Exposed LiteLLM Servers: A Detailed Look
Wiz’s scan identified 3,074 LiteLLM gateways on Shodan, with 294 accepting the example key. Of these, 191 did not have any key set, accepting any input, while the remainder retained the default setup guide value. A subsequent scan in August revealed over 85,000 instances, though most appeared to be honeypots or test systems, making direct comparisons difficult. As of September 9, the setup guide still advised users to replace sk-1234 with a random value prior to deployment.
The Critical Role of the Admin Key
The admin key in LiteLLM acts both as a credential and a key to enable authentication. In versions prior to 1.82.0-stable, gateways without a set master key automatically granted full admin rights. This access allows manipulation of API keys, viewing prompts and responses, and connecting to internal tools via the Model Context Protocol (MCP). Such vulnerabilities can lead to unauthorized usage of resources, termed LLMjacking, affecting the host’s cloud billing.
Additional Security Concerns and Flaws
LiteLLM’s ability to create pass-through endpoints poses further risk, as it allows administrators to forward requests to any URL, including private and cloud metadata addresses, potentially exposing IAM credentials. While no direct exploitations of this feature have been reported, it remains a significant concern. Wiz’s report also highlighted other vulnerabilities, including a post-authentication code execution flaw (CVE-2026-59821) and a guardrail sandbox escape (CVE-2026-40217), which have since been addressed in updates.
Despite these fixes, a separate flaw (CVE-2026-59822), allowing unauthorized MCP session access, continues to threaten LiteLLM. This vulnerability, exploited by attackers since July, enables unauthorized access to MCP tools using minimal bearer tokens.
Recommended Security Measures
Users are advised to upgrade to LiteLLM version 1.84.0 or later to mitigate known vulnerabilities. Additionally, changing the default admin key to a secure, random value is crucial. Blocking specific endpoints and restricting network access further enhance security. For systems that may have been compromised, reviewing and resetting key configurations is essential to restoring integrity. LiteLLM does not view the pass-through endpoint as a flaw, so network and IAM role restrictions remain the primary defenses.
As security threats continue to evolve, organizations must remain vigilant in their efforts to safeguard AI gateways and sensitive data.
