LiteLLM 1.107.0 Release Compromise (October 2026)

LiteLLM says its release pipeline was compromised and that version 1.107.0 reached PyPI and Docker registries with malware. The official v1.107.0 source tag on GitHub does not contain the malicious files, according to LiteLLM. On 24 October LiteLLM’s security lead wrote on GitHub issue 47826 that there is in fact no official v1.107.0 source tag. Seven wheels were uploaded to PyPI between 11:39:51 and 11:40:13 UTC, and the Docker image was published at 11:46:56 UTC.

PyPI removed the release at 13:23 UTC, per LiteLLM. LiteLLM says the affected GHCR tags were unavailable by 13:51 UTC and that all affected Docker Hub tags were removed or repointed to clean artifacts by 14:20 UTC. Its enterprise private release was not affected.

Times differ between sources. Wiz writes that the release was quarantined on PyPI “as of 1:20 UTC”. That is before the 11:39 upload, so it most likely means 13:20 UTC.

Wiz also says the images were removed around 13:53 UTC. StepSecurity says BerriAI confirmed the images gone at 14:32 UTC.

We use LiteLLM’s own times above and say where others differ. Our news post has a LiteLLM 1.107.0 response checklist.

LiteLLM’s response: on 21 October 2026 it removed the packages from PyPI, Docker Hub and GHCR and revoked the tokens involved. It removed all but one unaffected user from its GitHub organization.

It also removed trusted publishing links to the organization from public registries. It promised updates every two hours.

PyPI marked release 1.107.0 as quarantined, and the project page shows the badge “Release quarantined on Oct 21, 2026”. SafeDep reports that the account hosting the dead-drop file and its repository were deleted in the afternoon.

Update 23 October 2026: Microsoft Security published its own analysis of the release. It adds that starting Python in an affected environment can be enough to run the stealer and that recovery means rebuilding from verified artifacts, not deleting the litellm folder. See the sections on how it worked and the checks below.

Update 24 October 2026: LiteLLM published its root cause analysis on 23 October at 21:00 UTC. It says the master key of its experimental Agent Platform was committed to the public LiteLLM-Labs/lite-harness repository on 27 May 2026. The commit was force-pushed over, but the key was never revoked.

On 10 October the attacker used that key to read a GitHub organization owner’s GitHub CLI token from the platform. With that token, the attacker took the tokens of two more maintainers from CI secrets. LiteLLM says this replaces its first theory, that the tokens came from the logs of an internal deployment.

LiteLLM says three engineers’ GitHub accounts were used, through stolen GitHub CLI OAuth tokens. One account changed the release pipeline and triggered the run, another approved it and a third deleted workflow records.

Root cause, per LiteLLM’s analysis of 23 October: on 27 May 2026 a configuration file, opencode.json, was committed to the public LiteLLM-Labs/lite-harness repository. The file held the master key of a LiteLLM Agent Platform deployment, an experimental open source tool that runs cloud agents which open pull requests. LiteLLM says the mistake was caught quickly and the commit was force-pushed over. The exposed keys were marked for revocation, but the master key was never revoked.

The platform held a GitHub CLI OAuth token of a GitHub organization owner. LiteLLM says it was not tied to a service account and not scoped down. On 10 October the attacker used the master key to call the platform API, and one response returned that token.

LiteLLM notes that GitHub CLI tokens are issued after two-factor sign-in, so GitHub’s extra re-authentication step for sensitive actions did not apply. With owner rights the attacker pushed short-lived branches whose workflows posted CI secrets to a webhook.site endpoint, which gave them the tokens of two maintainers. LiteLLM says token hashes in the audit log tie one of them to the approval of the production gate on 21 October. The other matches the deletion of the workflow records.

LiteLLM also says it relaxed a release rule earlier that week. Until then, a special account locked to a device in its office had to approve each release. After the change, any two engineers could start and approve one.

LiteLLM adds that the owner token could have changed that rule too. It believes the attacker used separate tokens to avoid noisy audit logs.

In its incident post of 21 October (update of 20:30 UTC), LiteLLM had suspected that the tokens were taken from the logs of an internal deployment. It now says the request logs show that the first token came from the Agent Platform.

Socket and Wiz add that the build came from a lookalike repository, Berri-AI/litellm, one hyphen away from the real BerriAI/litellm. SafeDep shows that a build setting added a folder named cook to the wheels but not to the source archive. SafeDep rates as moderate to high confidence that the wheels came from attacker-modified source built by the project’s own release pipeline.

The wheels install three files into site-packages: cook.pth, cook.py and sitecustomize.py. The .pth file imports cook at every Python start, using Python Startup Hooks (T1546.018), so no import of litellm is needed. The stealer reads cloud, developer, CI and AI tool credential files and environment variables (Credentials in Files, T1552.001). When a database URL is set, it also reads the LiteLLM proxy tables that hold provider keys.

It encrypts the bundle and posts it to www.litellm[.]dev/healthcheck. The sitecustomize.py file starts a detached loader that checks a GitHub dead-drop file for a domain, then fetches and runs code from it. StepSecurity says the loader fails silently on Windows, while the stealer still runs.

This is a case of Compromise Software Supply Chain (T1195.002). Socket maps it to T1195.001, T1546.018 and T1552.001, among others.

Microsoft says the cook.pth file has a single executable line, import cook, that loads cook.py. That file decodes an embedded collector and runs it in a background thread.

Microsoft says the collector also reads Kubernetes service account files, Docker config and mounted secrets. On Linux, it reads the environment of other readable processes. On the proxy, it reads selected fields from two database tables, up to 500 rows per query.

Microsoft adds that the collector tries to get credentials from the AWS and Google Cloud metadata services. The bundle is encrypted with AES-256-CBC, the key is wrapped with an embedded 4,096-bit RSA public key, and the upload goes to the /healthcheck address.

Microsoft saw a routine Python command that installed an unrelated dependency on Windows start the collector. It maps the case to ATT&CK techniques including T1195.001, T1546.018, T1102.001 and T1105. It says no second-stage retrieval or execution was confirmed, including on the Unix loader path. Microsoft says the dead-drop file was empty when the researchers it cites examined it.

LiteLLM's own post names no actor. Its root cause analysis of 23 October says the attacker started with a master key that had been committed to a public repository on 27 May and never revoked. CERT-EU reported that the cybercrime actor TeamPCP compromised LiteLLM in March 2026, using the word "reportedly". No source cited on this page links the two events, so we do not.

Microsoft's post of 23 October says it has not independently determined how the developer credentials were first obtained. Socket reports that workflows collecting the project’s CI secrets ran in the BerriAI/litellm repository from at least 10 October 2026. At the time, it said it had not established how the attacker got access.

LiteLLM's analysis links that activity to the release. It says the audit log hash of the GH_TOKEN secret posted on 10 October matches the token that approved the production release on 21 October.

StepSecurity counts about 49,000 PyPI downloads of 1.107.0 before its removal, a figure that includes CI caches and mirrors and leaves out container pulls. Downloads are not infections. LiteLLM says to assume compromise if 1.107.0 ran in an environment, or if a container ran the affected image digest.

Wiz reports that about 4.5 hours after exfiltration the attacker validated AWS instance role credentials from two IP addresses. The calls were sts:GetCallerIdentity and then Bedrock model listing, which Wiz calls consistent with LLMjacking. Wiz says some environments also saw IAM enumeration.

StepSecurity also says the account that hosted the loader's dead drop has been deleted, but infected hosts keep polling it. See our dead drop explainer and the Dead Drop Resolver technique page.