The AI Gateway That Holds Every Key Was Poisoned

On October 21, 2026, a poisoned version of LiteLLM was published to the Python package index. LiteLLM is an open-source proxy that many companies put in front of OpenAI, Anthropic and other providers, so every model call and every provider key passes through one place. That is the convenience. It is also why this incident matters to anyone who runs, or is about to run, AI inside a business: the one box that holds all your model keys was the target, and the way in was an AI agent platform holding a token it should never have had.

We have no basis to say that Leverage or any client used LiteLLM or was affected. This is a read of what LiteLLM and an independent security database have published, and what it teaches an owner or COO who does not read package changelogs.

What happened

LiteLLM’s incident post is direct: “A malicious litellm==1.107.0 package was published to PyPI and was live for approximately 2 hours (11:39 UTC to 13:23 UTC). It has since been pulled. Docker images v1.107.0, latest, main-latest, and main-stable were compromised from 11:46 UTC to 14:20 UTC.”

Two details are worth slowing down for. First, “latest” was among the poisoned Docker tags, so anyone who simply pulled the newest image during those hours got it. Second, the company says the official source tag on GitHub does not contain the malicious files: “The compromised artifacts were built from an attacker-controlled repository.” Reading the code on GitHub would not have told you.

The guidance is equally plain: “If you ran pip install on LiteLLM v1.107.0 or started the docker image in the compromised interval, assume it is compromised. For the time being, please pin your version to 1.106.2 or any explicit version published prior to now.” Enterprise customers on LiteLLM’s private registry were not affected. LiteLLM says the disclosure of a separate vulnerability is scheduled for October 27.

What the bad version did

The independent record, MAL-2026-2144 in the OSV database, says litellm 1.107.0 “contains a credential stealer and a remote code execution backdoor that are not in the upstream source.” The payload “is triggered at every Python interpreter start, without importing litellm.” In plain terms, merely having it installed was enough; nobody had to use it. Whether it actually sent anything out depends on the host, and we have seen no confirmed victim count. LiteLLM’s own advice is blunt: “If 1.107.0 was ever installed on a host with outbound internet, assume the exfil succeeded.”

What it collects is a list of everything a technical person keeps within reach: “browser passwords and history, SSH keys, shell history, AWS/GCP/Azure credentials and cloud instance metadata … Kubernetes, Docker, Vault and CI secrets,” and AI developer tool configurations such as Cursor’s and Claude’s.

The chain, in four links

On October 23, LiteLLM published an account of how the attacker got in. None of the links is exotic.

1. An exposed key was not revoked. On May 27, 2026, a configuration file committed to a public repository “inadvertently contained the master key to a deployment of the LiteLLM Agent Platform, an open source tool we use for orchestrating agents.” The commit was quickly overwritten and the exposed keys were identified as “requiring revocation.” In the company’s own telling, the master key was not revoked. Overwriting a commit does not unpublish a secret that was already visible.
2. The agent platform held a person’s token. According to LiteLLM, “The token in question was not associated with a service account and was not scoped down. The key used was a GitHub CLI OAuth token associated with our GitHub organization owner’s account.”
3. That token meant owner access. “On October 10th, the threat actor used this key to gain access to our LiteLLM Agent Platform and extracted this GitHub CLI OAuth token. From this point onwards, the threat actor had owner-level access to all repositories in our GitHub.” Using that access, the attacker ran workflows meant to pull additional tokens out of CI secrets, including those of two engineers with maintainer privileges. The company adds that such tokens “are post-2fa and not subject to GitHub’s “super-user” 2fa reauth flows” — two-factor protection had already been satisfied when the token was issued.
4. A release safeguard had been loosened, though it may not have mattered. “In typical operation, building and publishing a release requires being kicked off by an authorized engineer and being approved by a special account locked to a physical device in our office. This restriction was relaxed earlier this week to accommodate the temporary push for more frequent releases and bugfix backports, allowing any two engineers to trigger and approve a release.” LiteLLM also notes that “armed with a token belonging to an organization owner, the threat actor could very well have relaxed this restriction (or removed it entirely) themselves.” Treat the loosened gate as a contributing factor; the owner-level token was the larger problem.

LiteLLM’s own summary: “This incident has provided a strong illustration of the risks associated with failing to rotate a potentially exposed key.” It says it is “revoking every token associated with every internal system and vendor platform.”

Why this matters if you are not a developer

Notice what the stealer went after: cloud credentials, CI secrets, and the configuration of AI developer tools. Those are the places a company’s AI keys end up. A gateway concentrates them on purpose, so that billing, logging and access sit in one place. That makes the gateway host the most valuable machine in the AI stack. Treat it like a password vault, not a utility script.

Notice also where the attacker began: not at the product, but at a platform that orchestrates AI agents and happened to hold a powerful person’s token. If you are deploying agents, each one is a place a credential can sit. We wrote about that pattern in the credential is the boundary and about the ownership gap in why an agent needs a manager, not just an API key. Agents exposed to the internet are covered in MCP servers on the public internet.

This is also a different failure from the one in when your AI vendor goes down. There, the dependency stopped working. Here, it kept working and worked for someone else.

What is not known

LiteLLM has not said how many installations pulled the bad release, and we cannot tell you. The bad package was live for about two hours and the Docker images for about two and a half. A short window is not a small number of installs, though: automated builds and update tools pull without anyone watching. LiteLLM says the disclosure of a separate vulnerability is scheduled for October 27.

What to do this month

None of these is expensive. Most are configuration and a decision about who owns each item.

• If you run LiteLLM, check the windows. Did anything install 1.107.0, or start the v1.107.0, latest, main-latest or main-stable images, between 11:39 and 14:20 UTC on October 21? If yes, treat the host as compromised and rotate every credential it could reach — provider keys, cloud credentials, SSH keys, CI secrets. LiteLLM recommends rebuilding images and environments from scratch over cleaning in place.
• Pin versions and image digests. A tag like “latest” is a moving target that someone else controls. Pin to an explicit version, ideally an image digest, and update on your schedule after a review.
• Give every agent its own service account with the narrowest scope. Never a person’s token, and never an owner’s. If an agent only reads one repository, its credential should read only that.
• Rotate any key that was ever exposed, even briefly. Rewriting history does not count as revocation. Put revocation on the checklist, with a named owner.
• Deny outbound traffic from the gateway host by default. A gateway needs to reach a short list of model providers. Allow those and nothing else, and a stealer has a much harder time sending anything home.
• Keep a hardware-bound approval gate on releases, and do not relax it under deadline. LiteLLM’s account shows a safeguard loosened for speed in the same week, although an owner-level token could have removed it regardless. So pair the gate with scoped credentials, and if a gate has to move, set an expiry date when you move it.

Owning it means owning this work

We build AI on infrastructure the client owns, and this incident is the honest cost of that choice. When the gateway, the agents and the keys sit in your environment, nobody else rotates, pins or locks them down for you. That work belongs on someone’s calendar, with a name next to it. If it is not on yours, a fractional CIO can own that list, and AI integration done properly includes the scoped accounts, the pinned versions and the outbound rules from the start.

The 30-second version

A poisoned LiteLLM release, built to steal credentials, was live on October 21. The way in was an unrevoked key, a person’s unscoped token on an agent platform, and a release gate that had been loosened, which an owner-level token could have removed anyway. Check whether you ran 1.107.0 or the affected images, pin what you run, give agents their own narrow accounts, rotate anything ever exposed, block the gateway’s outbound traffic by default, and keep your release gates.