LiteLLM 1.107.0 compromised with a Python startup credential stealer

On October 21, 2026, PyPI received litellm version 1.107.0 at 11:39 UTC. Wiz examined the published artifacts and found credential-stealing code in all seven platform wheels. In its official incident update at 16:00 UTC, LiteLLM says the PyPI wheels were available from 11:39:51 to 13:23 UTC and recommends pinning to 1.106.2 or an explicit version released before the incident; it says earlier releases are safe. PyPI currently marks 1.107.0 as quarantined. Check exact image digests and tag history for deployed containers rather than relying on the current value of a mutable tag. (LiteLLM official incident update; BerriAI security issue; Wiz artifact analysis; PyPI 1.107.0; PyPI 1.106.2)

How the release was compromised

BerriAI's October 21 20:30 UTC incident report says an attacker used a credential associated with an organization owner to override branch protections, force-push a modified release workflow, and run it against Berri-AI/litellm, a lookalike of the canonical BerriAI/litellm repository. That workflow signed and published artifacts built from the attacker-controlled repository; the official v1.107.0 source tag did not contain the malicious files. BerriAI says credentials associated with three engineers' GitHub accounts, apparently stolen GitHub CLI OAuth tokens, were used to trigger, approve, and delete workflow records. The tokens involved in that release attack were revoked. (BerriAI incident report; BerriAI security issue)

BerriAI says it observed situations where Claude Code can include a user's GitHub CLI OAuth token in a response body. If response bodies are logged, tokens can appear in LiteLLM logs. The company found an unexpected account in an internal LiteLLM deployment exposed to the public internet. BerriAI believes the attacker accessed that deployment and obtained tokens from its logs, but it has not confirmed the initial access method and currently suspects a recently patched vulnerability. This is the vendor's current hypothesis, not a confirmed root cause. (BerriAI incident report)

A later October 21 status in the BerriAI issue says the company is identifying and revoking or rotating organization authentication tokens. It reported no indication of exfiltration or improper use for the vast majority, while saying some initial-access questions remain unresolved. Registries remained locked to new releases and regular releases remained paused. The issue said the next status was due at 01:30 UTC on October 22. When rechecked at 02:20 UTC, no follow-up status was visible. This vendor statement does not establish that every token or environment is unaffected. (BerriAI security issue)

Wiz separately reported post-exploitation activity between 16:20 and 17:01 UTC on October 21, including validation of AWS instance-role credentials harvested from compromised CI runners and Kubernetes nodes, followed in a small number of environments by IAM and account discovery. This is Wiz's reported telemetry from that earlier window, not evidence of continued activity after BerriAI's later status. Wiz does not give a customer count. (Wiz post-exploitation findings)

Package and image scope

The affected Python release is litellm==1.107.0, with all seven wheels compromised according to Wiz and the vendor's incident report. LiteLLM says the v1.107.0, latest, main-latest, and main-stable Docker Hub tags pointed to a compromised image index from 11:46:56 to 14:20 UTC. The same tags on GHCR pointed to compromised image indexes from 11:46:56 UTC and were unavailable by 13:51 UTC. LiteLLM says the affected Docker Hub tags and image variants were removed or repointed to verified clean artifacts by 14:20 UTC. Its official report gives sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e for the compromised main image index; Wiz records these per-platform digests for the explicit v1.107.0 tags:

• ghcr.io/berriai/litellm:v1.107.0: amd64 sha256:bd1aeee419ea36da9aa2b657288da4101887be468f020ac63d22ba6ed84a3ea5; arm64 sha256:56b74573eed6e4aafe4b50603dbe7853e0345f188c8e44a09f1098caf1f4bcdf.
• ghcr.io/berriai/litellm-database:v1.107.0: amd64 sha256:24581ddc30767f16ecb69d2b0517556f2cd7dea56971adb42a3d1beb97d69523; arm64 sha256:827dd893c74cf621a860a66a3a447a5c732533f087589ce905573e285c0a239c.
• ghcr.io/berriai/litellm-non_root:v1.107.0: amd64 sha256:645a67d810628252d63df85dcc8824c58bcc77cf8383f4d3e6321f0ccc3ce9e4; arm64 sha256:f75c8edae59b72b1ebfd617295833f465c85bb2fab9c1d60f21b496db86cb8da.
• docker.io/litellm/litellm: Wiz records the same amd64 and arm64 digests as the main GHCR image.

These hashes identify the artifacts analyzed in the report. A mutable tag can point to a replacement image now, so compare digests and tag history rather than treating a current tag as proof of which bytes ran. LiteLLM says its private enterprise registry was not affected. The confirmed malicious PyPI release in the reviewed reports is the final 1.107.0. StepSecurity says its inspection found no payload in 1.107.0rc1 or 1.107.0rc2, and it lists stable 1.106.x versions as clean. It says the 1.107.0.dev1 through .dev3 pre-releases were not inspected. For companion packages, StepSecurity records litellm-proxy-extras versions 0.4.108 to 0.4.110 and litellm-enterprise versions 0.1.69.post2, 0.1.73.post1, and 0.1.76.post1 as reported clean in the original disclosure. BerriAI's issue says the 0.4.110 and 0.1.78 pins in version 1.107.0 were existing October 18 releases, not new uploads that day. These records distinguish the final malicious release from adjacent versions, and they do not establish the status of every development artifact or package.

What the payload did and what remains unknown

Wiz found cook.pth, cook.py, and sitecustomize.py in the package's site-packages root. The .pth hook runs at interpreter startup, so a Python program on an affected host could trigger it without importing LiteLLM. The embedded stealer targets browser, cloud, developer, and AI service credentials, including credentials stored by the LiteLLM proxy, and is designed to send collected data to an attacker-controlled lookalike domain. The separate sitecustomize.py loader attempted to retrieve a second-stage address from a GitHub dead drop. Wiz said that file still contained test values at the time of analysis, so the report does not establish that a second-stage payload was delivered. The published malicious artifacts establish that the code was in the release. The analysis does not give an installation count or establish how many environments completed exfiltration.

If version 1.107.0 or an affected image ran in an environment, treat credentials available to that process as exposed. Before starting Python or running pip in an affected environment, remove cook.pth, cook.py, sitecustomize.py, and matching startup-hook .pyc files from each affected site-packages directory using a method that does not launch that Python environment. LiteLLM's incident guidance warns that each Python startup reruns these hooks, including a pip invocation. Stop any detached malicious Python process found during investigation, then rebuild the virtual environment or image from a verified clean release. Revoke and replace provider API keys, cloud credentials, GitHub or CI tokens, and other secrets the runtime could read. Installing 1.106.2 alone does not remove files already written to an environment or invalidate secrets that may have been copied. (LiteLLM incident cleanup guidance; BerriAI incident issue)