LiteLLM Compromised, Steals Credentials

In a new incident, a malicious version (1.107.0) of the LiteLLM package was uploaded to PyPI and Docker on October 21. The malicious version includes a credential stealer targeting browser, cloud and AI secrets as well as a dormant C2 capability.

At 11:39 UTC on October 21, a malicious version (1.107.0) of the LiteLLM package was uploaded to PyPI. This version was quarantined on PyPI as of 13:20 UTC. Accordingto ClickPy data, the malicious version received approximately 49,000 downloads.

LiteLLM Docker containers on GHCR and Docker hub also included the trojanized version of LiteLLM. These included thev1.107.0,latest,main-latestandmain-stabletags. These were removed ~13:53 UTC.

The most recent safe version is v1.106.2.

When the malicious package is installed, three files are extracted directly into thesite-packagesroot:cook.pth,cook.pyandsitecustomize.py. These packages are designed to be executed whenever a python interpreter is started.

PerLiteLLM developer BerriAI:

malicious actions were taken through three engineers' GitHub accounts, appearing to be by way of stolen GitHub CLI OAuth tokens. The threat actor used one user's account triggered the project-releaser run, and another user's account to approve it. All tokens which were involved in this attack have been revoked.

Andin a followup:

GitHub CLI OAuth token exposure After a thorough investigation, we have observed specific situations in which Claude Code will embed a user’s GitHub CLI OAuth token into a response body, and in situations where response bodies are logged, these tokens may appear in LiteLLM logs. Access to our internal LiteLLM deployment We identified an unexpected, innocuously named user account in our internal LiteLLM deployment, which was exposed to the public internet. We believe the attacker gained access to this deployment, obtained the GitHub CLI OAuth tokens from its logs, and subsequently used those credentials to compromise our release workflow. We have not yet confirmed how the attacker gained access to our internal deployment, but currently suspect it was through a recently patched vulnerability.

UPDATES

14:05 UTC - added IOC table

14:15 UTC - added Attack Commits details

14:40 UTC - added Credential Stealer details, noted Docker takedown

15:20 UTC - clarified dual-technique approach novelty and LLM-aided development

16:40 UTC - added diagram of payload flow

16:55 UTC - added LiteLLM statement on root cause

18:35 UTC - LiteLLM hasreleased a blog post

19:05 UTC - added observed post-exploitation activity

21:45 UTC - updated LiteLLM details on root cause

October 22 12:55 UTC - added PyPi download stats

The payload has strong indications of LLM-aided development, including verbose variable names(encrypted_private_key_output), overly defensive error handling with generictry/exceptblocks, platform-specific code paths that fail silently on untested platforms (Windows marker path/tmp/doesn't exist,fcntl/forkcalls crash the remote loader), and a dead code module (exec_py) that was defined but never called. The structure suggests iterative prompting: functional on the happy path but brittle at the edges and untested.

Upon startup, the interpreter processescook.pth, which includes a command to importcook, which loadscook.py.cook.pydeobfuscates itself, runs a stealer routine and writes a maker to/tmp/.pc_once_72129118c59f5636c0bb(note this fails on Windows, as the /tmp/ path often does not exist). The stealer routine gathers system, browser, developer, cloud and AI tool secrets, encrypts them and exfiltrates towww.litellm.dev/healthcheckvia a post request. This domain is attacker controlled, impersonating LiteLLM infrastructure.

Python interpreters will also attempt to executesitecustomize.py- however, it will only run on Linux & MacOS machines. This script attempts to fetchdomain.txtfrom a GitHub dead drop (letters9813/pythonclient-test/main/domain.txt). If it receives a response, it will attempt to download a second stage python script fromhttp://<domain>/codepyand run it. As of the time of analysis, thedomain.txtfile was never populated beyond initial test values. The repo has been taken down by GitHub as of 1:30 PM UTC.

The dual-technique approach, using both.pthfiles andsitecustomize.pysimultaneously, appears to be the first documented case in the wild.

The embedded credential stealer, internally namedprivcollect, harvests sensitive data across 16 modules targeting browsers, cloud providers, and AI services. It extracts:

browser credentials and cookies from Chrome, Firefox, Edge, and Safari

AWS credentials from~/.aws/, environment variables, and EC2/ECS instance metadata (IMDS)

GCP service account keys and application default credentials

Azure tokens from the CLI cache

In terms of AI-specific theft, it targets API keys for OpenAI, Anthropic, Cohere, and other LLM providers stored in environment variables or config files. It also collects SSH private keys, GPG keys, and shell history files.

LiteLLM Proxy stores upstream API keys in a PostgreSQL database. The stealer queries this database directly (SELECT * FROM "LiteLLM_CredentialsTable" LIMIT 500) to extract all configured provider credentials.

Harvested data is encrypted with AES-256-CBC (key wrapped with RSA-4096) and exfiltrated over HTTP towww.litellm[.]dev/healthcheckusing the hardcoded X-Token header and an Internet Explorer 7 user-agent string.

The payload originates with malicious commits made ongithub.com/Berri-AI/litellm. Note, this is a hyphenated variant of the legitimate BerriAI organization. This repository, not visible on GitHub, was used to inject the payload into the release pipeline.

Between 08:56 and 10:46 UTC on October 21, the attacker pushed 10 commits using the author [email protected]. The first nine commits were created on GitHub.com and therefore signed with GitHub's verified signature.

The first three (within 2 minutes) added the persistence files:cook.pth,cook.py, andsitecustomize.py. Four more commits bumped version numbers to1.107.0.

After a 39-minute gap, two commits refined the payload and added the criticaldata = "cook"directive topyproject.toml, which instructed the build tool to bundle the malware into the wheel.

A final commit, made 58 minutes later with a different email ([email protected]) and unsigned (suggesting a different environment), addedCOPY cook ./cookto the Dockerfiles.

Although the Berri-AI repository is unavailable, all commits remain accessible through the parent repository due to Git's fork object sharing. The full diff is available at:github.com/BerriAI/litellm/compare/a8113b0d...20535d8f

Wiz Research hasobserved abuse of stolen credentials, starting approximately 4.5 hours post-exfiltration. Between 16:20 and 17:01 UTC, the attacker validated AWS instance role credentials harvested from compromised CI runners and Kubernetes nodes across multiple environments, from the following IP addresses:

168.100.8[.]57

165.227.201[.]8

Each credential was checked withsts:GetCallerIdentity, followed bybedrock:ListFoundationModelsand aListModelscall, consistent withLLMjacking.

In a small number of environments, the attacker also enumerated IAM (ListRoles,ListUsers,ListAccessKeys) and performed general discovery (ListAccounts,DescribeTrails, etc.).

Wiz customers should review our Threat Intel Center advisory:Supply Chain Attack Targeting LiteLLM.

Enable native runtime protection for GKE in just one click. The Wiz Runtime Sensor add-on now automates deployment and credential management while delivering predictable, kernel-level eBPF threat detection for your GKE Kubernetes fleets.

How a single Google Search ad click leads to credential theft, hijacking of cloud billing account, and hundreds of thousands of dollars incurred in unauthorized AI API usage

When trusted packages are compromised, malicious code can quickly spread throughout and beyond developer environments. See how Wiz’s supply chain pipeline identifies compromised packages at publication, helping teams detect zero-day supply chain compromises in Wiz Defend before a CVE is published

Get a personalized demo

©2026Wiz, Inc.

StatusPrivacy PolicyTerms of UseModern Slavery StatementCookie Settings