The LiteLLM Compromise: When Your AI Gateway Becomes the Credential Thief

On October 21, 2026, a malicious release of LiteLLM, the open-source gateway many teams use to route requests to AI model providers, was published to PyPI and to container registries. Version 1.107.0 carried a credential stealer and a loader for remote code. LiteLLM says its release pipeline was compromised, and Wiz reports that stolen cloud credentials were being tested by the attacker within hours.

This is the second supply chain incident for the project this year. The malicious versions were live for only a few hours, but the lesson is about what sits next to an AI gateway: cloud roles, provider API keys and developer tokens. This post covers what is confirmed, what is not, and what a GRC program should do this week.

What Happened

According to LiteLLM, attackers gained access to GitHub CLI credentials belonging to three engineers, one of which could run workflows. A token belonging to an organization owner was then used to weaken branch protections and point the release process at a lookalike repository, written with a hyphen as Berri-AI instead of BerriAI. The poisoned packages were built and signed from that repository. The official source tag did not contain the malicious files, which is why a review of the public code would not have caught it.

Endor Labs reports the application code itself was untouched. A single added line in the build configuration placed three extra files into the Python library directory. Python runs some of those file types at every startup, so the payload executed whenever Python launched in an affected environment, even if LiteLLM was never imported. Wiz describes this combination as apparently the first documented case of its kind in the wild.

Per the vendor and researcher write-ups, the stealer targets cloud credentials, SSH and GPG keys, browser data, shell history, CI secrets, API keys for AI tools, and the provider keys stored in a LiteLLM proxy database. Encrypted results were sent to a lookalike domain. A second component polled a pointer file on GitHub for instructions, which would have let the attacker run further code. Wiz says that file only ever held test values before it was taken down.

Timeline

October 19: LiteLLM temporarily widened release permissions for two engineers to publish backport fixes.
October 21, 11:39 UTC: The malicious version appears on PyPI. The vendor lists it as live until about 13:23 UTC.
October 21, 11:46 to 14:20 UTC: Docker Hub tags v1.107.0, latest, main-latest and main-stable served the bad build.
October 21, about 16:20 to 17:01 UTC: Wiz observed the attacker validating AWS role credentials taken from CI runners and Kubernetes nodes, consistent with abuse of stolen AI service access.

Confirmed vs Still Unclear

Confirmed by the vendor and corroborated by multiple researchers: the malicious artifacts and their publication windows, the lookalike repository, the unauthorized workflow changes, and the safe fallback version, 1.106.2. LiteLLM says customers on its private registry were not affected.

Not yet established:

How the attacker first got in. LiteLLM found an unexpected account in an internal deployment that was exposed to the internet and suspects a recently patched vulnerability, but says it has not confirmed this.
How many organizations ran the bad version. Wiz, citing public download data, puts downloads of 1.107.0 at roughly 49,000. Socket separately estimates about 23 million weekly downloads for the project overall. These measure different things and neither is a count of victims.
Attribution. A similar technique appeared in a March 2026 incident attributed to TeamPCP, but Socket reportedly found no evidence linking the two.
Exposure windows. Aikido gives an earlier end time for the PyPI window than the vendor does. Use your own install and pull logs, not a published window.

LiteLLM also states that tokens may have leaked through its logs, because Claude Code can include a user's GitHub CLI OAuth token in response bodies that were then recorded. That is the vendor's explanation, and Wiz presents it as LiteLLM's statement rather than its own finding.

Why This Is a GRC Problem

1. Do you know where AI gateways and proxies run?

Developers adopt tools like this quickly, often outside procurement. If your inventory tracks products you bought but not packages your teams install, you cannot answer whether 1.107.0 ever ran in your environment.

2. Unpinned dependencies are a change control gap

The affected installs were the ones that pulled whatever was newest. A build that accepts a new package version without review is an uncontrolled change to production code. Pinning versions and image digests, and using an internal package proxy, turns this into a reviewed change.

3. The blast radius is credentials, not just the package

Removing the package does not undo the theft. Endor Labs notes that uninstalling alone leaves the added files behind, and the vendor warns that running pip first in an affected environment can re-trigger the collector. Recovery means isolate, clean or rebuild, then rotate everything the process could read.

4. Third-party risk now includes the vendor's release pipeline

This compromise came from developer tokens and workflow permissions, not a bug in the product. Vendor due diligence should ask who can publish a release, how many approvals are needed, whether branch protections can be disabled by one account, and whether build provenance is checked against the reviewed source.

5. Secrets in logs are evidence you may not want

If the vendor's explanation holds, logging full response bodies exposed live tokens. Review what your own AI tooling logs, who can read those logs, and how long they are kept.

6. Evidence for auditors

Auditors will want to see that you scoped exposure, rotated credentials and recorded the decisions. Keep the install logs, CloudTrail queries and rotation tickets together.

Control Mapping

Framework	Relevant control area
NIST CSF 2.0	GV.SC (supply chain risk management), ID.AM (asset inventory), DE.CM (continuous monitoring), RS.MA (incident management)
ISO/IEC 27001:2022	A.5.21 ICT supply chain, A.5.17 Authentication information, A.8.32 Change management
SOC 2	CC8.1 (change management), CC9.2 (vendor risk)

I have kept this table to mappings I am confident in. Map further controls to your own framework scope.

Action Plan

Next 24 hours

Search lockfiles, CI logs, container images and package proxy logs for litellm 1.107.0 and for the affected image tags and digests. Check the October 21 window for any unpinned install.
If found, isolate the host before doing anything else. Do not run Python or pip there. Remove the added files and stop the background process, or rebuild from a clean image.
Rotate the cloud role, proxy provider keys, database password, GitHub and registry tokens, SSH keys and any secrets in the environment. Rotate from a clean machine.
Review CloudTrail for identity checks and model listing calls from unfamiliar addresses around the install time.
Pin to 1.106.2 or another verified version and block 1.107.0 in your package proxy.

Next 7 days

Use the indicators the vendor and researchers published to hunt across endpoints and egress logs. The vendor notes that finding the files confirms exposure, but not finding them does not prove a system is clean.
Ask your AI and developer tooling owners for a list of gateways, proxies and agents in use and how each is deployed.
Check what your tools log and whether tokens appear in those logs.

Next 90 days

Require hash-pinned lockfiles and image digests for production builds.
Add alerts for new startup-hook files in third-party packages.
Add release pipeline controls to your vendor assessment for critical software suppliers.
Move developers from long-lived personal tokens to short-lived, scoped credentials.

Final Thoughts

The technical event was short. The organizational question is whether you can say, within a day, which systems pulled a package during a three-hour window and which secrets those systems could reach. Teams with pinned builds and a current inventory will answer quickly. Teams without them will be reconstructing it from logs.

The investigation is ongoing and the vendor is still updating its account, so confirm versions, indicators and guidance against LiteLLM's own incident notice and the researchers' advisories before acting on any single article, including this one.