Nearly one in 10 internet-exposed LiteLLM AI gateways accepted the widely documented default master key, sk-1234, or required no authentication, creating a direct path to LLMjacking, sensitive credential exposure, and in vulnerable versions root-level code execution inside the gateway container.
Their internet scan of 3,074 publicly reachable instances found that 294 systems, or 9.6%, accepted the default key; 191 instances, or 6.2%, had no authentication enabled.
The most severe externally reachable issue, tracked as CVE-2026-59822, affects LiteLLM’s Model Context Protocol (MCP) Streamable HTTP endpoint.
Before LiteLLM 1.84.0, an attacker could supply an arbitrary Bearer token and trigger an OAuth2 fallback path that converted a failed API-key validation into an empty authenticated user object.
In practice, even a single-character token could establish a valid MCP session and reach configured MCP tools without a legitimate LiteLLM key.
That matters because MCP servers often expose actions, not just data. Depending on deployment configuration, a compromised gateway could provide access to internal databases, source-code repositories, ticketing systems, Slack workspaces, file stores, CI/CD tooling, and other connected enterprise services.
The flaw has been added to CISA’s Known Exploited Vulnerabilities catalog, indicating exploitation has been observed in the wild.
A second issue, CVE-2026-59821, affected LiteLLM’s Custom Code Guardrails feature.
The production create and update endpoints previously compiled and executed submitted Python code without applying the sandboxing and dangerous-pattern validation enforced by the UI testing workflow.
Wiz researchers identified multiple flaws affecting LiteLLM, the open-source gateway used to centralize access to LLM providers such as OpenAI, Anthropic, AWS Bedrock, Azure, and Google Vertex AI.
LiteLLM AI Gateways
A privileged user capable of creating or modifying a guardrail could execute Python in the LiteLLM proxy environment, potentially exposing process secrets and running commands with the permissions of the service container.
The issue affects versions prior to 1.82.0-stable and has been fixed in 1.82.0-stable.
The Web UI’s “Run Test” button validates code against a forbidden patterns list and strips __builtins__ before execution, blocking import, os, subprocess, and similar. But the registration endpoint (POST /guardrails) applies neither protection.
In the researchers’ proof of concept, code executed during guardrail registration and returned uid=0(root) from the LiteLLM container.
The practical severity depends on the container’s runtime configuration, mounted secrets, Kubernetes service-account tokens, network reachability, and cloud IAM role permissions.
Root inside a container is not automatically root on the host, but it can still represent a high-impact foothold in an AI or cloud environment.
The risk becomes substantially worse when organizations leave LiteLLM’s master key unchanged or run the service with no authentication.
Historically, LiteLLM treated a missing master key as unauthenticated access and, before the relevant fix, assigned incoming requests the PROXY_ADMIN role.
This could turn exposed instances into remotely manageable administrative gateways rather than simple unauthenticated API proxies.
LiteLLM subsequently changed the default unauthenticated role and added stronger admin checks for guardrail operations.
Researchers also highlighted a cloud credential-theft scenario involving LiteLLM pass-through endpoints. The feature enables administrators to proxy requests to specified URLs, including internal addresses.
If an attacker obtains administrative access, they could configure a route targeting cloud metadata services such as AWS EC2 IMDS at 169.254.169.254 and retrieve temporary IAM credentials.
Although this behavior is framed as an administrative capability rather than a standalone vulnerability, it becomes dangerous when administrative access is obtained through default credentials, absent authentication, or another authorization flaw.
A related authorization issue, CVE-2026-35029, allowed authenticated users to exploit missing authorization checks on LiteLLM’s /config/update endpoint.
Red Hat says the flaw could permit proxy and environment-variable changes, potentially leading to remote code execution, unauthorized server-file access, and privileged-account takeover.
Organizations operating LiteLLM should upgrade immediately to at least version 1.84.0 to address the MCP authentication bypass and ensure they are running 1.82.0-stable or later for the Custom Code Guardrails fix.
They should also review whether CVE-2026-35029 remediation is present in their deployed release.
Administrators should replace sk-1234 with a strong, unique master key; disable or tightly restrict /mcp/ access if MCP is not essential; audit configured MCP servers and tool permissions; inspect existing guardrails and pass-through routes.
LiteLLM gateways should be treated as Tier-1 infrastructure. They sit between application workloads, model providers, cloud credentials, prompts, internal tools, and automation systems making a poorly secured gateway far more valuable to attackers than a conventional API proxy.
★ Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.
