The LiteLLM Compromise: AI Gateways Are Now Supply-Chain Targets

LiteLLM is a popular open-source gateway that gives applications one API in front of many large language model providers. That convenience is why it's an attractive target: a single LiteLLM deployment often holds API keys for several AI vendors, plus cloud credentials, in the same process.

On 21 October 2026, attackers used it exactly that way.

What Happened

• The attackers obtained developer credentials and tampered with the project's release workflow.
• They published a malicious LiteLLM 1.107.0 to PyPI and pushed compromised container images to Docker registries.
• According to LiteLLM's incident report, the PyPI packages were live from 11:39 to 13:23 UTC, and affected Docker Hub images from about 11:46 to 14:20 UTC.
• The payload stole credentials and opened remote access. It targeted browser credentials, cloud secrets, developer tokens and AI-service API keys.

The packages were pulled within hours. That's fast, but anything that installed latest or an unpinned range in that window ran the malware with whatever permissions it had.

Why AI Gateways Make Good Targets

• Key concentration. One process holds keys for OpenAI, Anthropic, Google, Azure and more, often with no spend limits.
• Fast-moving installs. AI tooling is frequently installed from scratch in notebooks, CI jobs and side projects without lockfiles.
• Broad network access. Gateways need outbound access to many providers, which makes exfiltration traffic look normal.
• Weak ownership. Many deployments started as experiments and never got an owner, monitoring or a patch process.

If You Installed 1.107.0

LiteLLM's guidance is to treat the environment as compromised:

1. Identify exposure. Search lockfiles, image digests and CI logs for litellm==1.107.0 or images pulled during the window above.
2. Rebuild, don't clean. Destroy affected containers, VMs and CI runners, and redeploy from a known-good version.
3. Rotate everything reachable. AI provider keys, cloud credentials, tokens in environment variables and any browser-stored secrets on developer machines that ran it.
4. Check usage. Review billing and usage logs at each AI provider for activity you don't recognise. Stolen model keys are often resold for compute.

Controls That Contain the Next One

None of these is new, and all of them would have limited this incident:

• Pin exact versions and verify hashes. Use lockfiles with integrity hashes (pip --require-hashes, uv.lock, pnpm or npm lockfiles), and pin container images by digest, not tag.
• Add a release cool-down. Don't auto-adopt a dependency release until it has been public for a few days. Most malicious releases are caught within hours.
• Verify provenance. Prefer packages published through trusted publishing, with attestations, and check them where your tooling allows.
• Keep secrets out of the process. Fetch provider keys from a secrets manager with short-lived credentials, and scope each key to one service with spend limits.
• Restrict egress. A gateway only needs to reach its model providers. An allowlist turns credential exfiltration into a blocked connection and an alert.
• Protect your own release pipeline. If you publish packages, use hardware-backed MFA, trusted publishing instead of long-lived tokens, and required reviews on release workflows.

The Takeaway

The LiteLLM attack wasn't sophisticated. Stolen credentials, a tampered release and a short window were enough. AI infrastructure has inherited every classic supply-chain risk while concentrating more valuable secrets in fewer places. Run it like production, because it is.

Sources

• LiteLLM incident report
• Wiz: LiteLLM compromised, steals credentials
• SecurityWeek coverage
• Black October (Wikipedia)