LiteLLM deployments can expose far more than an organization’s AI spending. Newly disclosed weaknesses in the open-source gateway could let attackers run code as root inside a container, reach connected tools, and retrieve cloud credentials that open a path into a wider environment.
The risk is serious where the service is internet-facing or retains its example master key. A gateway sits between applications, model providers, internal data, and automation, so its compromise can turn one overlooked service into a central point of failure.
Researchers at Wiz.io identified the issues while examining public LiteLLM installations. Their scan of 3,074 internet-facing instances found that 294, or 9.6%, accepted a default master key or had no authentication enabled.
Wiz.io said in a report shared with Cyber Security News (CSN) that the MCP authentication bypass, tracked as CVE-2026-59822, was observed in the wild through its honeypot systems.
CISA added the flaw to its Known Exploited Vulnerabilities catalog on September 2, increasing urgency for organizations with reachable instances.
LiteLLM Flaws Let Attackers Execute Code
CVE-2026-59821 affects LiteLLM’s Custom Code Guardrails feature, which lets administrators supply Python-like policies that run around model requests.
Before the fix, the endpoint used to register a guardrail did not apply the safety checks present in the testing interface, allowing supplied code to execute immediately.
The result could be root-level command execution in the LiteLLM container when an attacker had administrative access.
That access may be available where authentication is absent, the default master key remains, or another administrative weakness is abused. Readers can compare it with the earlier LiteLLM admin API flaw, which affected configuration controls.
The RCE requires an authenticated administrator and cannot be reached solely through the MCP bypass. Yet weak deployment settings can remove that barrier.
In releases before version 1.82.0, an unchanged default credential could make the code-execution path effectively available before normal authentication.
The MCP issue creates a different entry point. A meaningless Bearer token could establish a valid session with a connected MCP server, potentially allowing an intruder to use available database, repository, file-system, or workflow tools.
This differs from the LiteLLM RCE exploitation in the wild, which involved another vulnerability chain. LiteLLM corrected the guardrail weaknesses in release 1.82.0 by enforcing an administrator role and applying sandbox protections during registration.
It later fixed the MCP authentication bypass in version 1.84.0. Organizations should identify their version, patch promptly, and check for exposed older containers or test instances.
Cloud Keys at Risk
The findings show why AI gateways require the protection given to other privileged cloud services. LiteLLM may hold provider API keys and communicate with internal systems, while its workload identity can carry permissions to invoke models, read secrets, or interact with other cloud services.
A pass-through feature can forward requests to an administrator-defined destination without checking whether it is an internal address or cloud metadata service. With administrator access, an attacker could use it to obtain temporary AWS IAM credentials.
It is not a standalone vulnerability, but it becomes hazardous when access controls fail. The configuration-update route controlling pass-through settings also lacked an administrator check before version 1.83.0, a separate issue tracked as CVE-2026-35029.
The pattern is reflected in AI infrastructure credential theft, where exposed gateways can bridge attackers to secrets, persistence, and costly resource misuse.
Administrators should replace example credentials with a strong, unique master key and review guardrails for unexpected entries. Restarting the process can clear code retained in memory.
They should audit pass-through settings, restrict container outbound traffic, and apply least-privilege IAM permissions to workload identities.
Remove management interfaces from the public internet and limit access to trusted networks and authenticated administrators.
Rotate provider keys and cloud credentials if an exposed vulnerable instance might have been accessed, then review logs for suspicious administrative activity and unusual outbound requests.
The LiteLLM supply chain exposure likewise shows why gateways need careful configuration, identity, and update control.
Indicators of compromise (IoCs):-
| Type | Indicator | Description |
|---|---|---|
| Default credential | sk-1234 |
Default LiteLLM master key accepted by exposed deployments |
| HTTP endpoint | /mcp/ |
MCP endpoint affected by the authentication-bypass issue |
| HTTP header value | Authorization: Bearer a |
Minimal Bearer-token value demonstrated to establish an MCP session |
| HTTP endpoint | /guardrails |
Guardrail registration endpoint associated with custom-code execution |
| HTTP endpoint | /config/pass_through_endpoint |
Endpoint used to configure pass-through request routes |
| URL | http://169.254.169.254/latest/ |
AWS instance metadata service target used in the cloud-credential theft demonstration |
| File name | user_api_key_auth_mcp.py |
LiteLLM MCP authentication-handler source file |
| File name | guardrail_endpoints.py |
LiteLLM guardrail-endpoint source file |
| File name | custom_code_guardrail.py |
LiteLLM custom-code guardrail source file |
| File name | pass_through_endpoints.py |
LiteLLM pass-through endpoint source file |
Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.
Keep your SOC up to date on active malware & phishing within 24h of their emergence. Try ANYRUN to prevent incidents with early detection.
The post LiteLLM Flaws Let Attackers Execute Code as Root and Steal Cloud Credentials appeared first on Cyber Security News.