Security Concerns Emerge Surrounding LiteLLM AI Gateways
Recent findings reveal alarming security vulnerabilities in LiteLLM AI gateways, which have become a focus of concern for cybersecurity professionals. An extensive internet scan, involving 3,074 publicly accessible instances of these gateways, disclosed that nearly one in ten accepted the default master key, sk-1234, or even allowed user access without authentication. This put systems at risk for LLMjacking, credential theft, and even potential root-level code execution within the gateway containers.
Specifically, the investigation uncovered that 294 of these systems, representing 9.6% of the scanned instances, accepted the default key, while 191 instances, or 6.2%, had no form of authentication enabled. The implications of these weaknesses are profound and could expose sensitive enterprise data to malicious actors.
Among the vulnerabilities identified is a severe issue cataloged as CVE-2026-59822, affecting the Model Context Protocol (MCP) Streamable HTTP endpoint within LiteLLM. Prior to version 1.84.0, an attacker could manipulate an arbitrary Bearer token, triggering an OAuth2 fallback mechanism that would convert failed API key validation into an authenticated user session with empty credentials. In a practical scenario, even a mere single-character token could establish a valid MCP session, providing access to a range of configured MCP tools without necessitating an authentic LiteLLM key.
This vulnerability is particularly consequential because MCP servers often enable actions, not just data retrieval. Depending on how the gateways are configured, compromised systems could grant access to internal databases, source code repositories, ticketing systems, Slack workspaces, file storage solutions, CI/CD tooling, and various other enterprise services. Notably, this flaw has garnered enough attention to be included in the Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerabilities catalog, indicating that it has been exploited in real-world scenarios.
Another identified security flaw, CVE-2026-59821, revolves around the Custom Code Guardrails feature of LiteLLM. Here, the production create and update endpoints were discovered to compile and execute submitted Python code without the necessary sandboxing or validation checks usually enforced by the UI testing workflow. This oversight could have dire consequences, as it allows privileged users to execute arbitrary Python code within the LiteLLM proxy environment, exposing crucial process secrets and granting command execution with service container permissions.
Wiz researchers, who conducted the examination, pointed to multiple vulnerabilities affecting LiteLLM, an open-source gateway integral in centralizing access for LLM providers like OpenAI, Anthropic, AWS Bedrock, Azure, and Google Vertex AI.
The issue of executing Python code in the LiteLLM environment depends significantly on the configuration of the container’s runtime, particularly concerning mounted secrets, Kubernetes service-account tokens, and IAM role permissions. While root access within a container does not automatically imply root access on the host system, it still represents a notable risk, especially in AI and cloud environments.
Compounding these issues is a historical tendency for LiteLLM to treat missing master keys as equivalent to unauthenticated access. Before necessary fixes were implemented, incoming requests could be assigned the PROXY_ADMIN role by the system, effectively transforming exposed instances into manageable administrative gateways rather than simple API proxies. LightLLM has since adjusted its security protocols, changing the unauthenticated role and imposing more stringent admin checks for guardrail operations.
Additionally, researchers highlighted a concerning scenario involving cloud credential theft through LiteLLM pass-through endpoints, which allow administrators to proxy requests to specified URLs, including internal addresses. If an attacker gains administrative access, they could exploit a route targeting cloud metadata services, such as AWS EC2’s Instance Metadata Service (IMDS), retrieving temporary IAM credentials.
While this behavior is typically viewed as an administrative capability, it becomes perilous when an attacker exploits default credentials or other authorization flaws to gain access. Another related concern, labeled as CVE-2026-35029, allowed authenticated users to bypass authorization checks on LiteLLM’s /config/update endpoint, leading to potential issues such as remote code execution, unauthorized access to server files, and privileged account takeovers.
Given these vulnerabilities, organizations utilizing LiteLLM are urged to upgrade to at least version 1.84.0 to rectify the MCP authentication bypass and to ensure they are running version 1.82.0-stable or later for the Custom Code Guardrails fix. Additionally, it is crucial for administrators to replace the default master key sk-1234 with a robust, unique key, and to carefully audit configured MCP servers and tool permissions.
LiteLLM gateways, sitting at the intersection of application workloads, model providers, and cloud credentials, should be treated as Tier-1 infrastructure. A poorly secured gateway poses a much higher risk than a standard API proxy, making it an attractive target for attackers seeking to exploit vulnerabilities for malicious purposes. The urgency for comprehensive security measures cannot be overstated, as the ramifications of these vulnerabilities could extend far beyond individual organizations.