LiteLLM says a malicious 1.107.0 release was published through three engineers' GitHub accounts, apparently with stolen GitHub CLI OAuth tokens; StepSecurity and Wiz say the 1.107.0 PyPI wheels and Docker images carried a credential stealer and an hourly remote-code loader (21 Oct); pin 1.106.2
Oliver Jensen of LiteLLM (its director of security, according to The Hacker News) said in the project's GitHub issue #47826 on 21 October 2026 that LiteLLM was treating a report of a compromised 1.107.0 release as SEV-0, that PyPI had quarantined 1.107.0, and later that the malicious Docker images had been removed. In a status update at 16:32 UTC (00:32 Perth, 22 Oct) LiteLLM said the malicious actions were taken through three engineers' GitHub accounts, 'appearing to be by way of stolen GitHub CLI OAuth tokens', with one account used to trigger the project-releaser run and another to approve it; it said all tokens involved have been revoked, that it has not yet identified how the attacker got them and so cannot yet assert there is no further access to those accounts, that as a temporary measure it removed all but one unaffected user from its GitHub organisation, and that it removed trusted links from public registries to its GitHub organisation to stop further malicious publication. LiteLLM told open-source users to pin 1.106.2 or another explicit earlier version, and said its private enterprise registry is not affected. Wiz says the malicious 1.107.0 was uploaded to PyPI at 11:39 UTC on 21 October and that the v1.107.0, latest, main-latest and main-stable Docker tags on GHCR and Docker Hub also carried it until they were removed at about 13:53 UTC. StepSecurity says all seven 1.107.0 wheels drop cook.pth, cook.py and sitecustomize.py into site-packages, so the payload runs on every Python start in that environment even if litellm is never imported; it says the first payload is a credential stealer that calls itself privcollect, taking browser passwords, SSH and GPG keys, cloud credentials, AI tool tokens and the provider API keys stored in the LiteLLM proxy database, and the second checks a GitHub dead drop every hour and runs whatever Python the attacker serves. StepSecurity says the git tag is clean and the release was built from a lookalike repository, Berri-AI/litellm, and that stolen data is sent to the lookalike domain litellm.dev. Wiz says the dead-drop file was never populated beyond initial test values at the time of its analysis and that GitHub had taken the repository down. Primary: LiteLLM status updates in GitHub issue #47826; research: StepSecurity, Wiz; wire: The Hacker News (21 Oct). UPDATE (22 Oct, 5:45 am Perth): LiteLLM's incident post on docs.litellm.ai (21 Oct) says the 1.107.0 PyPI wheels were live from 11:39 to 13:23 UTC, that the Docker Hub v1.107.0, latest, main-latest and main-stable tags pointed to the compromised image from 11:46 to 14:20 UTC, and that the same GHCR tags did so until they were made unavailable by 13:51 UTC; it says you are affected if you installed an unpinned LiteLLM with pip in that PyPI window or used those Docker images in that Docker window. LiteLLM's timeline says a credential associated with a privileged developer account was used at 10:08 UTC to override GitHub branch protection and change its private release workflow, a credential associated with a second developer account satisfied the production approval gate at 11:11 UTC, and credentials associated with a third developer account were used at 11:53–11:54 UTC to delete the production and staging workflow records, which limited the logs available for investigation. In an 18:30 UTC status update (2:30 am Perth) LiteLLM said it had identified a potential vector through which one of the auth tokens leaked but not yet how the attacker moved to the other affected engineers' accounts, that it had seen no ongoing suspicious activity, and that its image registries stay locked to new releases, so ordinary LiteLLM releases are paused; at 20:31 UTC it said it believed it had identified the attack chain and would publish a description. Wiz said in a 19:05 UTC update that it has observed abuse of stolen credentials starting about 4.5 hours after 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 168.100.8[.]57 and 165.227.201[.]8, checking each with sts:GetCallerIdentity followed by bedrock:ListFoundationModels and a ListModels call, which Wiz says is consistent with LLMjacking; in a small number of environments the attacker also enumerated IAM and performed general discovery. UPDATE (22 Oct, 8:30 am Perth): In a status update at 21:22 UTC on 21 October (5:22 am Perth 22 Oct), also added to its incident post, LiteLLM said it believes it has identified the attack chain and that the attacker had to compromise multiple independent security controls. LiteLLM says it had hardened its release pipeline after a prior incident in March (releases from a private repository through Trusted GitHub Publishers, immutable Docker release tags, signed Docker images, and publishing only from an account locked to one office laptop), but that 'on Monday' it had temporarily expanded release permissions so two internal engineers could publish daily bugfix backports. According to LiteLLM, the attacker held three developers' GitHub CLI credentials, one of which could run GitHub workflows and one of which belonged to one of its two GitHub organisation owners; after failing to merge a change that would let the releaser point at a different source repository, the attacker used the owner's token to disable branch protections and force-push the change, then ran the compromised workflow against a lookalike repository (Berri-AI/litellm instead of BerriAI/litellm), which signed and published the poisoned artifacts. LiteLLM says it has observed specific situations in which Claude Code embeds a user's GitHub CLI OAuth token in a response body, so that where response bodies are logged the tokens may appear in LiteLLM logs; it says it found an unexpected, innocuously named user account in its own internal LiteLLM deployment, which was exposed to the public internet, and believes the attacker accessed that deployment and took the GitHub CLI OAuth tokens from its logs. LiteLLM says it has not yet confirmed how the attacker got into that internal deployment but suspects a recently patched vulnerability, and that it is still confirming parts of this account and building a timeline. At 23:37 UTC (7:37 am Perth 22 Oct) LiteLLM said it was identifying and revoking or rotating every authentication token across the organisation as a precaution, that for the vast majority it had seen no sign of exfiltration or misuse, that some questions about initial access remain unresolved, and that its registries remain locked and regular releases paused, with the next update due at 01:30 UTC.
- Product
- LiteLLM (BerriAI) Python SDK and AI gateway proxy — PyPI package and Docker images
- Versions
- Compromised: litellm 1.107.0 on PyPI (all seven wheels; the sdist has a tampered build config but no payload, per StepSecurity) and the v1.107.0 Docker images for ghcr.io/berriai/litellm, litellm-database, litellm-non_root and docker.io/litellm/litellm, plus the latest, main-latest and main-stable tags while they pointed to it on 21 Oct (StepSecurity, Wiz). Safe pin: 1.106.2 (LiteLLM). LiteLLM says its private enterprise registry is not affected. LiteLLM's exposure windows on 21 Oct: PyPI 11:39–13:23 UTC; Docker Hub tags 11:46–14:20 UTC; GHCR tags from 11:46 UTC until unavailable by 13:51 UTC. As of 22 Oct.
- Exploited in Australia?
- unknown
- Patch to
- LiteLLM: pin litellm 1.106.2 or another explicit version published before the malicious release. StepSecurity: if 1.107.0 was installed from a wheel, or you ran a LiteLLM container pulled on 21 Oct, treat that host as fully compromised; kill any detached Python process holding /tmp/remote_code_loader.lock, delete cook.pth, cook.py and sitecustomize.py from site-packages, pin litellm==1.106.2 (or the v1.106.2 image by digest), then rotate every credential the host could reach (cloud keys and instance roles, SSH and GPG keys, browser passwords, AI tool tokens, CI and Vault secrets, and every provider API key in the LiteLLM proxy database) and block litellm.dev. The remediation in the GitHub issue report adds: do not start with pip install in an affected environment, because any Python start re-runs the payload, and prefer rebuilding environments and images from scratch. StepSecurity notes many projects depend on LiteLLM with an open-ended litellm>= constraint, so check lockfiles refreshed on 21 Oct. LiteLLM's incident post: check with pip show litellm; treat any container that ran image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e as compromised; search for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py (finding one confirms exposure, not finding one does not prove the environment is clean); rotate the instance/task IAM role, every provider key in the proxy DB plus master and virtual keys, the DATABASE_URL password and any secret in the host's process environments; and check CloudTrail for GetCallerIdentity from the instance role around install time and later use of its credentials from outside your infrastructure. Wiz: look for activity from 168.100.8[.]57 and 165.227.201[.]8. If you run your own LiteLLM proxy with request or response body logging, LiteLLM's attack-chain findings (21 Oct UTC) mean those logs may hold GitHub CLI OAuth tokens: keep the deployment off the public internet, review its user accounts, and revoke any GitHub tokens that appear in its logs.
Primary: LiteLLM (BerriAI) GitHub issue #47826 — status updates from LiteLLM's Oliver Jensen (21 Oct 2026) · Vendor: StepSecurity — litellm 1.107.0 compromised on PyPI: backdoored wheels drop a credential stealer and an hourly remote code loader (21 Oct 2026) · Wiz — LiteLLM compromised, steals credentials (21 Oct 2026)