Cybersecurity firm **Wiz Research** has uncovered a widespread misconfiguration impacting **LiteLLM**, an open-source AI gateway. Their February scan revealed that nearly one in ten internet-facing **LiteLLM** servers accepted 'sk-1234', the example admin key provided in **LiteLLM**'s own setup guide. This default key acts as both the administrator credential and the switch enabling authentication for the gateway. Its presence allows unauthorized users to access critical data, including every model provider's API key stored on the server. In **Wiz**'s tests, this access also extended to the cloud IAM credentials of the underlying machine hosting the gateway. ### The Scale of Exposure **Wiz**'s initial scan in February identified 3,074 **LiteLLM** gateways on **Shodan**, with 294 of them accepting the 'sk-1234' key. Disturbingly, 191 of these 294 instances had no key set at all, rendering them vulnerable to any input. While a later August scan found over 85,000 instances, **Wiz** believes most were honeypots or test systems, making direct comparison difficult. As of September 9, the **LiteLLM** setup guide still includes 'sk-1234', albeit with a cautionary note advising users to replace it before production use. This continued inclusion contributes to the persistence of the vulnerability. ### Why a Single Key Matters So Much The gravity of this default key stems from its dual function: it's both the administrative credential and the authentication enabler. Prior to version 1.82.0-stable, a gateway launched without a master key implicitly granted full administrative rights to all incoming requests. An administrator with control over such a server gains extensive access. This includes reading API keys for all routed providers, monitoring all prompts and responses, and connecting to internal tools via the Model Context Protocol (MCP). Furthermore, these gateways often run with the cloud permissions of their deployment environment, making them a prime target for 'LLMjacking'—where attackers exploit stolen provider keys to run model workloads on the victim's dime. ### Reaching Cloud Accounts **LiteLLM** allows administrators to create pass-through endpoints that forward requests to any specified URL. Crucially, the target URL is not validated against private address ranges, localhost, or cloud metadata addresses. This loophole enables an attacker with admin access to direct a route to the instance metadata service and extract IAM credentials. Even with **IMDSv2**, this exploit is possible. **LiteLLM**'s documentation notes that headers with an `x-pass-` prefix are forwarded to the target, allowing **Wiz** to send the necessary **IMDSv2** headers. While no real-world exploitation of this specific path has been reported, it serves as a stark demonstration of the potential for cloud compromise once admin access is gained. **LiteLLM**'s project maintainers argue that this functionality is working as intended, as their threat model considers administrators trusted. Consequently, there is no **CVE** or specific fix for this behavior, and setup mistakes like not setting a master key are explicitly out of scope for their security policy. ### The Guardrail Flaw and Disputed Severity **Wiz**'s report also details **CVE-2026-59821**, a code execution flaw. **Wiz** describes it as post-authentication root-level code execution, demonstrating `uid=0(root)` within the gateway container. Conversely, **LiteLLM**'s advisory for the same **CVE** rates it as Low (CVSS 2.1), stating it requires a high-privilege account.  Both parties agree on the underlying behavior: before 1.82.0-stable, endpoints for custom code guardrails bypassed sandbox and pattern checks. An attacker with access to these endpoints could submit Python code to run inside the container. The **LiteLLM** advisory clarifies that deployments without a master key treated all callers as proxy administrators, making these endpoints accessible. **Wiz**'s report suggests that after 1.82.0, code execution was limited to a sandbox. However, **LiteLLM**'s own records, specifically **CVE-2026-40217** (published in May), indicate that the sandbox could be escaped using bytecode techniques in versions up to 1.83.10, with the proxy process often running as root in default **Docker** images. This exploit also required a proxy-admin credential, which the master key provides. Both flaws reported by **Wiz** were patched in February and April, with their **CVEs** published in July, months before **Wiz**'s September 9 report. ### Other Exploited LiteLLM Flaws Several other **LiteLLM** vulnerabilities have already seen active exploitation: * **CVE-2026-59822** (CVSS 8.8): Added to **CISA**'s Known Exploited Vulnerabilities catalog on September 2. This flaw, also discovered by **Wiz**, allows an unauthenticated attacker to establish a valid **MCP** session using any **Bearer** token, even a single-character one. **Wiz** observed it being used against its honeypots starting July 7 to probe model listing endpoints. Federal civilian agencies are mandated to address this by September 16. * **CVE-2026-42271** (CVSS 8.7): This flaw enabled authenticated users to execute commands on the host through **MCP** test endpoints. **Horizon3.ai** reported in June that it could be chained with **CVE-2026-48710**, a **Starlette** host-header flaw, to achieve unauthenticated command execution. **Wiz**'s honeypots recorded this flaw being used to install cryptocurrency miners. * **Microsoft** detailed an August incident where attackers exploited **CVE-2026-42271** and **CVE-2026-48710** to run commands within a **LiteLLM** gateway process. They then extracted the master key, provider keys, and database connection strings from the container's environment, subsequently accessing the underlying **PostgreSQL** database to copy records. **Microsoft** strongly advises treating **AI** gateways as "Tier-0 secrets stores." ### Immediate Recommendations To mitigate these critical vulnerabilities, organizations using **LiteLLM** should immediately upgrade to version 1.84.0 or later. This update addresses all the flaws detailed in the advisories. Furthermore, it is imperative to replace the default 'sk-1234' administrator key with a strong, unique, and randomly generated value before any real-world deployment.