Hackers Can Turn Vulnerable LiteLLM AI Gateways Into Root Access and Cloud Credential Theft
Wiz found multiple LiteLLM AI gateway flaws, including a CVE-2026-59822 MCP auth bypass added to CISA KEV, enabling root code execution and cloud credential theft.
An internet scan of 3,074 exposed LiteLLM instances found 294 (9.6%) accepting the default sk-1234 master key and 191 (6.2%) requiring no authentication. CVE-2026-59822 lets a single-character Bearer token establish a valid MCP session via an OAuth2 fallback in versions before 1.84.0; the flaw is in CISA's Known Exploited Vulnerabilities catalog. CVE-2026-59821 allows Python code execution as root in the gateway container via unsanitized Custom Code Guardrails registration before 1.82.0-stable, and CVE-2026-35029 permits config changes leading to RCE and admin takeover. Admin access plus pass-through endpoints can reach cloud metadata services to steal IAM credentials.
- 9.6% of exposed LiteLLM gateways accept default sk-1234 master key
- CVE-2026-59822 MCP bypass added to CISA KEV, exploited in the wild
- Guardrails flaw yields root code execution inside gateway container
- Pass-through endpoints can target EC2 IMDS to steal IAM credentials
- Upgrade to 1.84.0+ and replace default keys with strong unique keys
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2026-35029 | Broken Access Control in LiteLLM AI Gateway Enables Authenticated RCE CVE-2026-35029 is a broken access control flaw (CWE-863, CWE-425) in LiteLLM, an open-source proxy server (AI Gateway) for calling LLM APIs, in which the /config/update endpoint fails to enforce admin-role authorization in versions prior to 1.83.0. Any user who is already authenticated to the proxy can call this network-accessible endpoint without admin rights and modify the proxy configuration and environment variables. Through this, an attacker can achieve remote code execution by registering pass-through endpoint handlers that point to attacker-controlled Python code, read arbitrary server files by setting UI_LOGO_PATH and fetching the file via /get_image, and take over other privileged accounts by overwriting the UI_USERNAME and UI_PASSWORD environment variables; related security coverage also highlights that vulnerable LiteLLM gateways can be turned into root-level code execution and cloud credential theft. Any organization running a LiteLLM proxy older than v1.83.0 is affected, particularly deployments where non-admin users hold authenticated accounts. No public proof-of-concept or confirmed in-the-wild exploitation is known and the flaw is not in CISA KEV, but EPSS assigns a 25.1% probability of exploitation within 30 days (98th percentile), signaling elevated near-term risk. Do: Upgrade to LiteLLM v1.83.0 or later. Until patched, restrict network access to /config/update so only administrators can reach it, and limit how many non-admin accounts hold API/UI credentials on the proxy. Audit configuration and environment variables for tampering (especially UI_USERNAME, UI_PASSWORD, UI_LOGO_PATH, and registered pass-through handlers), and rotate cloud credentials stored in the gateway's environment if compromise is suspected. | 8.7 | 25% |
| moderateon the order of thousands of self-hosted gateway deployments (estimate; no published install counts) | ||
| CVE-2026-59821 | LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to 1.82.0-stable, LiteLLM's Custom Code Guardrails production create and update paths did not apply the same sandboxing and validation used by the test endpoint, allowing a privileged user with access to create or update guardrails to submit custom Python code that executed in the LiteLLM proxy environment and could expose secrets available to the process. This issue is fixed in version 1.82.0-stable. NVD description · AI analysis pending | 2.1 | <1% |
| — | ||
| CVE-2026-59822 | Unauthenticated MCP Endpoint Authentication Bypass in BerriAI LiteLLM BerriAI LiteLLM, a widely used self-hosted AI gateway and proxy server for calling LLM APIs, fails to properly authenticate requests to its MCP Streamable HTTP endpoint in versions prior to 1.84.0. An unauthenticated attacker can send a fabricated Authorization header that triggers an OAuth2 passthrough fallback, which replaces failed LiteLLM key validation with an empty UserAPIKeyAuth() object and lets the request reach MCP tooling without any valid LiteLLM key. Successful exploitation grants unauthenticated access to the gateway's MCP tooling with high confidentiality impact per the CVSS 4.0 score of 8.8, and public reporting describes attackers chaining LiteLLM weaknesses from authentication bypass to root code execution and cloud credential theft. Any organization running LiteLLM before 1.84.0 is affected, particularly gateways exposed to the internet. The flaw is confirmed exploited in the wild: CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-02, while EPSS currently estimates a 0.9% probability of exploitation in the next 30 days. Do: Upgrade LiteLLM to version 1.84.0 or later immediately, in line with the CISA KEV required action and BOD 26-04 guidance for internet-exposed assets. Audit whether the MCP endpoint is reachable from the internet and check for signs of exploitation, including unexpected MCP tool calls, use of fabricated Authorization headers, and use of default or example admin keys such as 'sk-1234'. Until patched, restrict access to the MCP endpoint and review cloud credentials accessible from the gateway host for signs of theft or root-level activity. | 8.8 | <1% | KEV |
| moderateon the order of thousands of internet-exposed LiteLLM gateway instances (estimate; no authoritative total) |
Full article772 words · extracted from gbhackers.com · click to collapse
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.
Mayura Kathirhttps://gbhackers.com/
Mayura Kathir is a cybersecurity reporter at GBHackers News, covering daily incidents including data breaches, malware attacks, cybercrime, vulnerabilities, zero-day exploits, and more.
Text extracted automatically; images, tables and formatting may be missing. Original: https://gbhackers.com/litellm-ai-gateways/