The AI Gateway Held the Keys. Attackers Turned LiteLLM Into a Credential and Persistence Hub.
Microsoft has documented real compromises of internet-exposed LiteLLM gateways in which attackers harvested model-provider credentials, queried the gateway’s PostgreSQL backend, installed cryptomining components and created durable access on the host.
This is no longer only a patching story. The gateway sat between applications and multiple AI providers, so one compromised runtime exposed far more than a single service. It put upstream API keys, LiteLLM master and virtual keys, database connection strings, routing configuration and tenant policy within reach of the attacker.
Microsoft assesses with high confidence that initial access likely came through the exposed LiteLLM surface. The observed activity is consistent with a public chain combining CVE-2026-42271, command execution through LiteLLM’s MCP test endpoints, and CVE-2026-48710, a Starlette Host-header validation bypass. Microsoft does not claim that it proved this precise chain in every affected environment.
Update, 2 September 2026: CISA adds two more exploited paths
CISA has added CVE-2026-59822 and CVE-2026-48710 to its Known Exploited Vulnerabilities catalogue. Federal civilian agencies have until 16 September 2026 to apply the mitigations. CISA lists ransomware use as unknown and has not published campaign details.
CVE-2026-59822 is a separate LiteLLM authentication bypass affecting versions before 1.84.0. A fabricated Bearer token could establish an authenticated MCP session, allowing an attacker to list and call configured tools and reach connected services. Upgrade to LiteLLM 1.84.0 or later. If that is not immediately possible, disable the MCP routes or block /mcp/ and related endpoints at the reverse proxy.
CISA’s addition of CVE-2026-48710 also changes the status of the Starlette half of the chain described below. It is no longer only a public reproduction or plausible amplifier. CISA now confirms known exploitation.
Update sources: CISA Known Exploited Vulnerabilities catalogue, entries added 2 September 2026 with remediation due 16 September 2026, and the LiteLLM advisory for CVE-2026-59822, published 30 June 2026 and updated 22 July 2026. The sources provide dates but no publication times.
The exploitation warning was already there
The LiteLLM flaw was disclosed in April as an authenticated command-execution vulnerability. Two MCP preview endpoints accepted a complete stdio server configuration, including the command, arguments and environment fields, then spawned the supplied command as a subprocess with the privileges of the LiteLLM proxy.
The original advisory said any holder of a valid proxy API key, including a low-privilege internal user, could reach the vulnerable code. Horizon3 later demonstrated that an affected Starlette dependency could undermine that authentication boundary and turn the route into unauthenticated remote code execution on exposed deployments.
| Vulnerability | Impact and prerequisites | Affected versions | Fix and workaround | Exploitation status |
|---|---|---|---|---|
| CVE-2026-42271 | LiteLLM MCP test endpoints can execute an attacker-supplied stdio command. The original route requires a proxy API key, but the public chain can remove that requirement in affected configurations. | LiteLLM 1.74.2 through 1.83.6 | Upgrade to 1.83.7 or later. If that is not immediately possible, block POST /mcp-rest/test/connection and POST /mcp-rest/test/tools/list at the reverse proxy or gateway. | CISA added it to KEV on 8 June 2026. Public reproduction and a Nuclei detection template are available. |
| CVE-2026-48710 | Malformed Host values can make request.url.path disagree with the path used for routing, bypassing security checks that trust the reconstructed URL. | Starlette 1.0.0 and earlier | Upgrade to 1.0.1 or later. A front-end proxy helps only if it rejects or normalises malformed Host headers and no attacker-controlled forwarded host is trusted. | Publicly reproduced as the authentication-bypass half of the LiteLLM chain. Microsoft describes the chain as relevant public context for its observed compromise. |
CISA gave federal civilian agencies until 22 June to apply the LiteLLM mitigation. Horizon3 published its chain on 1 June at 21:21 UTC and later updated the research on 1 August at 20:48 UTC. The LiteLLM and Starlette advisories list publication dates but no publication times.
The gateway became the attacker’s starting process
The most useful evidence in Microsoft’s report is the process lineage. Shells, Python one-liners, downloaders and second-stage payloads originated from the LiteLLM gateway process. That relationship turns an otherwise noisy Linux alert into a high-value signal: an AI routing service should not be launching command interpreters or reading its own process environment for secrets.
- Credential harvesting: the payload read
/proc/1/environin containerised deployments and filtered for provider API keys, the LiteLLM master key, database URLs, UI credentials, tokens and passwords. - Database collection: Python code parsed the gateway’s database connection string, connected to Azure Database for PostgreSQL and queried LiteLLM model and virtual-key tables.
- Exfiltration: collected output was base64-encoded and sent in small chunks through out-of-band callback infrastructure, with several outbound tools used as fallbacks.
- Payload delivery: the gateway retrieved an ELF binary, staged it under temporary paths and launched it with names and arguments chosen to resemble ordinary Linux services.
- Resource hijacking: XMRig or related components prepared the host for RandomX mining and removed competing miner persistence.
- Persistence: attackers wrote an SSH key for a service account, created cron entries, used hidden relay files and set immutable attributes to resist cleanup.
Microsoft also observed outbound traffic to raw IP infrastructure on port 81, use of sslip.io, and callbacks to out-of-band testing domains. These are not generic LiteLLM indicators. They are campaign-specific pivots that should be correlated with gateway-originated execution and secret access.
An AI gateway is a secret concentrator
Organisations often deploy an AI gateway to simplify authentication, routing, cost control and policy enforcement across many model providers. That convenience concentrates authority. The gateway may know how to reach every provider, which keys each team uses, how traffic is routed and where its control database lives.
That makes the security boundary more comparable to a privileged identity broker or secrets service than to an ordinary application proxy. A host compromise can become a cross-provider credential incident, a database incident and a persistence incident at the same time.
What defenders should do now
- Confirm versions and dependency trees. Upgrade LiteLLM to 1.84.0 or later and Starlette to 1.0.1 or later. Do not assume a newer LiteLLM container is safe without checking the resolved Starlette version.
- Remove management exposure. Restrict the LiteLLM API, UI and administrative surfaces to trusted networks. Block the two MCP test endpoints if an immediate upgrade is impossible.
- Treat exposed gateways as potential credential incidents. Rotate provider keys, LiteLLM master and virtual keys, database credentials and any other secrets available to the gateway process.
- Hunt by process ancestry. Investigate shells, Python, curl, wget or package installation launched by the gateway. Look for reads of
/proc/1/environ, LiteLLM database-table names and unexpected PostgreSQL clients. - Check persistence and staging locations. Review SSH
authorized_keys, cron, hidden files under temporary directories, immutable attributes and binaries masquerading as service processes. - Constrain egress. Allow only required model-provider and service endpoints. Alert on raw-IP connections, unusual ports, DNS rebinding services and OAST callbacks from the gateway runtime.
- Reduce the blast radius. Use per-team provider or virtual keys with spend limits, a managed secret store, a dedicated service account and least-privilege access to the gateway database.
Microsoft published the incident analysis on 26 August 2026 at 16:43:53 UTC, or 18:43:53 in Europe/Madrid. No later update timestamp was provided. Its larger message is operational: defenders should monitor AI gateways according to their control-plane role, not as isolated web applications.
Update, 1 September 2026: the database itself had an exploited injection path
The observed Microsoft incidents are consistent with the CVE-2026-42271 and CVE-2026-48710 chain described above. They do not prove use of CVE-2026-42208. The omitted vulnerability is still operationally significant because it reaches the same secret-concentrating database.
CVE-2026-42208 is a SQL injection flaw in LiteLLM 1.81.16 through 1.83.6. It can let an attacker read or modify the proxy database, creating access to model configuration, virtual keys and other credentials managed by the gateway. Version 1.83.7 contains the fix.
CISA added the vulnerability to its Known Exploited Vulnerabilities catalogue on 8 May. Teams should verify the LiteLLM version, review database audit logs for unusual queries and changes, rotate secrets reachable through the proxy, and avoid assuming that container replacement invalidates credentials already copied by an attacker.
Primary sources: LiteLLM security advisory and the CISA KEV catalogue.
Sources and further reading
- Microsoft Security: When AI infrastructure becomes the target, published 26 August 2026 at 16:43:53 UTC.
- LiteLLM advisory: Authenticated command execution via MCP stdio test endpoints, published 21 April 2026. No time provided.
- Horizon3: LiteLLM unauthenticated remote code execution chain, published 1 June 2026 at 21:21:01 UTC; updated 1 August 2026 at 20:48:57 UTC.
- Starlette advisory: Missing Host header validation, published 21 May 2026. No time provided.
- CISA Known Exploited Vulnerabilities catalogue, LiteLLM entry added 8 June 2026.
- ProjectDiscovery Nuclei template, public detection template for the LiteLLM command-injection route.
