LiteLLM Release 1.107.0 Carried a Credential Stealer After a Pipeline Breach

LiteLLM, a library and proxy that connects software to model providers, published a malicious release on 21 October 2026. Attackers used stolen developer tokens to run the project’s release pipeline against a lookalike repository. The poisoned version 1.107.0 reached PyPI at 11:39 UTC and Docker registries at 11:46 UTC, according to LiteLLM.

The release carried a credential stealer that runs whenever any Python program starts, including programs that never import LiteLLM. Wiz and Datadog both describe the payload, and LiteLLM says the affected releases have been pulled.

How the Release Workflow Was Changed Before Upload

LiteLLM’s incident page lists an unauthorised change to its private release workflow at 10:08 UTC. A privileged developer credential overrode branch protection to apply it. The modified workflow started a staging run against Berri-AI/litellm, an attacker-controlled repository, at 10:46 UTC. A second developer credential then passed the production approval gate at 11:11 UTC.

Seven malicious wheels were uploaded to PyPI between 11:39 and 11:40 UTC. LiteLLM says PyPI removed the release at 13:23 UTC. Datadog and Wiz put the quarantine at about 13:20 UTC and the Docker removal at about 13:53 UTC. LiteLLM says the Docker Hub tags stayed active until 14:20 UTC, and that GHCR tags were unavailable by 13:51 UTC.

A third developer credential deleted the production and staging workflow records at 11:53 UTC, which limited the logs available, according to LiteLLM. The unauthorised workflow revision was removed and the workflow restored between 12:09 and 12:24 UTC.

The page also gives the start of the compromise as 4:00 AM PST, which is 12:00 UTC. That is later than the 11:39 UTC upload the same page lists.

Exposure Window
LiteLLM says the malicious PyPI wheels were live from 11:39 to 13:23 UTC on 21 October 2026, and the Docker Hub tags from 11:46 to 14:20 UTC; GHCR tags were unavailable by 13:51 UTC.

How Stolen Developer Tokens Reached the Build

LiteLLM says the attacker held three sets of developer GitHub CLI credentials, one of which could run workflows. Release permissions had been temporarily expanded on Monday so two internal engineers could publish backports. A change to point the releaser at a different source repository was blocked. The attacker then used a token belonging to one of two GitHub organisation owners to disable branch protections and force the change through.

Datadog reports that the build ran against Berri-AI/litellm, a fork whose name differs from the real repository by one hyphen. The resulting packages recorded the fork as their source.

According to The Hacker News, Oliver Jensen, LiteLLM’s director of security, said the malicious actions were taken through three engineers’ GitHub accounts. He also said all tokens involved have been revoked. LiteLLM has not yet determined how the attacker obtained the tokens, and The Hacker News reports that LiteLLM cannot yet rule out further access to those accounts.

LiteLLM also says GitHub CLI tokens may appear in its logs when response bodies are logged. Its page says Claude Code can embed a user’s GitHub CLI OAuth token in response bodies. LiteLLM identified an unexpected, innocuously named user account on its internal, publicly exposed deployment, and believes the attacker gained access to that deployment and got the tokens from its logs. It suspects a recently patched vulnerability but has not confirmed how the attacker got into that deployment.

What the Payload Does and Where It Sits on a Host

The malware adds three files to site-packages: cook.pth, cook.py and sitecustomize.py. Python reads .pth files at startup, so the code runs before LiteLLM is imported. Datadog reports that deleting the litellm package does not remove these files, and that running python or pip triggers the malware again. The files must be removed by hand.

Wiz reports that the stealer collects browser credentials and cookies from Chrome, Firefox, Edge and Safari. It also gathers AWS, GCP and Azure credentials, API keys for AI providers such as OpenAI, Anthropic and Cohere, and SSH and GPG keys. Upstream provider credentials are queried directly from a LiteLLM Proxy PostgreSQL database.

According to Wiz, harvested data is encrypted with AES-256-CBC, with the key wrapped using RSA-4096, and sent over HTTP POST to a lookalike domain. The Hacker News describes the upload as a gzip-compressed tar archive sent to a health-check endpoint. It also gives the stealer’s internal name as privcollect. Datadog lists the wider target set as Kubernetes, Vault and Terraform credentials, npm, PyPI and Git tokens, and browser passwords.

How Harvested Cloud Keys Were Used, and the Backdoor Stage

Wiz observed the attacker validating AWS instance role credentials harvested from compromised CI runners and Kubernetes nodes, starting about 4.5 hours after exfiltration. Between 16:20 and 17:01 UTC, the attacker ran an identity check on each credential, then model-listing calls in Bedrock. Wiz says this is consistent with LLMjacking. In a few environments, the attacker also enumerated IAM users, roles and access keys.

The backdoor’s second stage has not been confirmed to have run. The Hacker News describes a background daemon that checks a GitHub dead-drop file every hour. If the file holds a domain, the malware runs the stealer again, requests code from that domain and executes the response. The Hacker News says the repository returned a 404 error, and Wiz says GitHub removed the repository at 1:30 PM UTC.

Wiz says the dead-drop file was never populated beyond initial test values, so the second stage was never observed active. Datadog reports only test values and says no second-stage payload was observed in the wild. Wiz says the check sits in sitecustomize.py, which runs only on Linux and macOS.

Not finding one does not prove the environment is clean.

Rollback and Rotation for Production Teams

LiteLLM recommends pinning to 1.106.2 or any version published before the incident. The Hacker News advises pinning by digest. LiteLLM prefers rebuilding images and virtual environments from scratch. Its page also says the official v1.107.0 source tag on GitHub does not contain the malicious files.

LiteLLM says not to run pip first, because any Python start re-runs the malicious files. On each affected host, it advises deleting cook.pth, cook.py, sitecustomize.py and matching cook*.pyc and sitecustomize*.pyc files from every affected site-packages folder. It then says to kill the detached Python process holding /tmp/remote_code_loader.lock.

LiteLLM lists the instance or task IAM role, every provider key stored in the proxy database, master and virtual keys, the DATABASE_URL password, and any secret in the environment of processes on the host. Wiz names AWS, GCP and Azure credentials. Datadog adds SSH, GPG and package-registry tokens, along with browser passwords and cookies, and advises rotating from a clean machine. Datadog also recommends locking release workflows to approved repositories and treating developer CLI tokens as high-value secrets.

LiteLLM advises checking CloudTrail for GetCallerIdentity calls from an instance role around install time. It says a host where 1.107.0 was installed and had outbound internet access should be assumed to have sent data out. Finding one of these files confirms exposure, but not finding one does not prove the environment is clean.

Status, the Enterprise Release and an Earlier Incident

The latest update on LiteLLM’s incident page is timed 20:30 UTC on 21 October, and the company says its investigation is ongoing. LiteLLM says its enterprise release and private registry were not affected. The enterprise registry distributes an embargoed release that fixes a vulnerability, scheduled for disclosure on 27 October. Wiz reports roughly 49,000 downloads of the malicious version, according to ClickPy data.

Datadog describes this as the second LiteLLM supply chain compromise in 2026. The earlier one affected versions 1.82.7 and 1.82.8, and Datadog Security Research links it to TeamPCP activity. Datadog says no connection between the two incidents has been established. The Hacker News places the earlier compromise in March, during the TeamPCP supply chain attacks, and says the same cook.pth launch behaviour was observed then.