The LiteLLM Compromise: Lessons for Securing AI Supply Chains

On October 21, a malicious version of LiteLLM, the open-source gateway many teams use to route application traffic to large language model providers, was published to PyPI, Docker Hub and GitHub Container Registry. According to the maintainers, litellm==1.107.0 "contained compiled malware which steals credentials and loads remote-code execution tools." The PyPI wheels were live for about an hour and 43 minutes; the Docker Hub tags, including latest, pointed to the compromised image for about two and a half hours.

Short windows matter less than they sound for a package this widely used. BleepingComputer puts LiteLLM at about 92 million monthly PyPI downloads. And this was the project's second compromise of 2026: in March, a separate attack published backdoored versions after a CI/CD dependency was poisoned. On October 23, LiteLLM published a detailed account of how the attacker got in this time. It is worth reading closely, because almost every step is something that could happen in any engineering organization, whether or not it runs AI workloads.

How the attacker got in

LiteLLM's attack-chain post, which it calls the canonical record (it corrects parts of the first incident post), describes a chain of small gaps:

• A leaked key that was never revoked. On May 27, a configuration file committed to a public LiteLLM repository contained an administrative key for an internal agent platform deployment. The file was deleted about three hours later, but the commit stayed in public history until October 22, and, in the maintainers' words, "nobody followed through on revoking the administrative key."
• An agent platform holding a human's token. On October 10, the attacker used that key to call the platform's API, which returned the configuration of every managed agent, including the GitHub CLI OAuth token of a GitHub organization owner.
• CI secrets exfiltrated through CI itself. With owner-level access, the attacker ran workflows on October 10 and 12 that posted repository secrets to an external webhook, collecting tokens belonging to two more maintainers.
• Protections overridden, not bypassed. On release day, the attacker changed the release workflow so it could build from a different source. Branch protection rejected a maintainer's push, so the attacker used the owner's token to override it, then pointed the build at a fork under a lookalike organization, Berri-AI instead of BerriAI.
• A two-person rule satisfied by one person. A rule allowed any two engineers to trigger and approve a release. The attacker used one stolen maintainer token to trigger the release and another to approve it. A third token was later used to delete the workflow run records.

Notably, the first incident post says LiteLLM had already hardened its pipeline after March, including Trusted Publishers, immutable Docker tags and signed images. Those controls did not stop the attack, because the attacker ran the project's own release pipeline. The artifacts were produced by the legitimate process, from attacker-chosen source.

Why an AI gateway is a high-value target

An LLM gateway sits in front of every model provider an organization uses, so it tends to hold exactly the secrets an attacker wants. JFrog's analysis of the malicious wheels shows the stealer went after cloud credentials for AWS, Azure and Google Cloud, Kubernetes tokens, SSH and GPG keys, CI/CD and Terraform secrets, browser data, credentials for AI development tools, and every readable process environment on Linux. It also read LiteLLM's own proxy database tables holding stored provider credentials and model settings. LiteLLM says the attacker's activity on other systems was aimed at "upstream inference API tokens."

The delivery mechanism is also worth understanding. The wheels added a cook.pth file that Python executes at interpreter startup, so, as JFrog notes, the payload "can run even when an application never imports litellm." A sitecustomize.py file started a detached process that checked a GitHub-hosted pointer every hour and could download and run more code. Stolen data was encrypted and sent to a lookalike domain. One practical consequence: running pip or Python inside an affected environment to investigate it re-runs the malware.

Who was affected, and what to do if you were

LiteLLM says users were affected if they ran an unpinned pip install during the PyPI window or ran the affected Docker images during their windows. Customers pulling from LiteLLM's private enterprise registry were not affected, and all versions before 1.107.0 are described as safe. The maintainers and JFrog give consistent guidance for anyone exposed:

1. Don't start with pip. Remove cook.pth, cook.py, sitecustomize.py and their compiled files using tools that don't launch the affected interpreter, and stop the detached Python process.
2. Rebuild rather than clean. Rebuild virtual environments, hosts and images from verified artifacts; LiteLLM points to 1.106.2 as the clean version.
3. Assume exfiltration. If 1.107.0 ran on a host with outbound internet access, treat everything it could reach as stolen. Both sources warn that a missing marker file does not prove a host is clean.
4. Rotate broadly. That includes the instance or task IAM role, all provider keys stored in the proxy database, LiteLLM master and virtual keys, the database password, source-control and package-publishing tokens, and any secret in process environments.
5. Check for use. LiteLLM suggests looking in AWS CloudTrail for GetCallerIdentity calls from the instance role around install time, and for those credentials being used from outside your infrastructure. JFrog adds DNS and proxy log searches for the exfiltration domain.

The broader lessons for any software supply chain

Most organizations don't publish packages to PyPI, but nearly all of them consume open-source packages and run CI/CD pipelines with powerful tokens. The LiteLLM chain maps cleanly onto those environments.

Secret leaks need revocation, not deletion

Deleting a file does not remove it from Git history, and the key in this case stayed valid for more than four months. A leaked credential should be treated as compromised the moment it is found: revoke, rotate and confirm, then clean up history.

Agents and automation shouldn't borrow human owner tokens

An agent platform stored an organization owner's personal OAuth token, and one API call exposed it. Automation should run on its own narrowly scoped, short-lived identities, and no workload should hold a token that can change organization-wide security settings.

CI secrets are reachable by anyone who can run a workflow

The attacker didn't need to break into a secrets manager; they ran workflows that sent secrets out. Limit which identities can create or dispatch workflows, scope secrets to the environments and branches that need them, and restrict outbound network access from build runners where you can.

Approvals are only as strong as the accounts behind them

Two-person rules assume two different people. When approval tokens can be stolen, require phishing-resistant authentication for release approvals, alert on branch-protection overrides and force-pushes to release branches, and send audit logs somewhere a compromised admin can't delete them.

Pin what you consume

Only unpinned installs and mutable tags like latest picked up the malicious release automatically. Pinning dependency versions with hashes, deploying container images by digest, and adding a short delay before adopting brand-new releases all reduce exposure to a compromise that is caught within hours. BleepingComputer reports several security firms flagged this release within minutes; a cooling-off period lets that detection work for you.

Checklist: what to do this week

1. Find LiteLLM. Search lockfiles, images and running containers for litellm, and confirm nothing ran 1.107.0. If anything did, follow the response steps above.
2. Inventory your AI gateways and agent platforms. List which provider keys, cloud roles and source-control tokens each one can reach, and cut that set down.
3. Audit long-lived tokens. Find personal access and OAuth tokens used by automation, especially any with organization owner or admin rights, and replace them with scoped service identities.
4. Review historical secret leaks. Re-check past secret-scanning alerts and confirm every exposed credential was actually revoked, not just removed from the code.
5. Harden release and deploy pipelines. Restrict who can edit or dispatch release workflows, alert on protection overrides, and keep CI logs in tamper-resistant storage.
6. Pin and delay. Enforce hash-pinned dependencies and digest-pinned images in production, and set a minimum package age for automatic upgrades.

The bottom line

The LiteLLM compromise didn't rely on a novel exploit. It chained a leaked key nobody revoked, a human token stored where automation could reach it, and release controls that trusted any valid credential. AI infrastructure concentrates valuable secrets, which makes those ordinary gaps more expensive. Baygramm's cybersecurity team helps organizations assess software supply-chain exposure and respond to credential compromise, our DevOps practice helps harden CI/CD pipelines and secrets handling, and our AI agents team helps design agent platforms with scoped, auditable identities. If you're not sure what your AI gateway can reach, talk to us.