LiteLLM 1.107.0 backdoored on PyPI and in official Docker images: credential stealer plus hourly remote-code loader runs on every Python start
Update Oct 23-25, root cause: LiteLLM's root-cause analysis says a master key for its internal LiteLLM Agent Platform was committed to a public repo on May 27 and was never revoked. On Oct 10 the attacker used it to read the platform's agent configs, which held an unscoped GitHub CLI token of a GitHub organization owner. With that token the attacker ran throwaway CI workflows that posted two maintainers' tokens and other secrets to webhook.site. On Oct 21 it overrode branch protection to point the release workflow at a lookalike fork (Berri-AI/litellm), approved the production gate with a second maintainer's token (a temporary rule change that week let any two engineers trigger and approve releases), then deleted the run records with a third token and force-pushed the history clean. Artifacts were live about two hours. Indicators include IPs 69.48.229.143 and 199.91.221.39. Microsoft's analysis adds Defender detections and hunting queries, and warns not to run python or pip inside a suspect environment to check for the package, because that alone can trigger the stealer.
On Oct 21, litellm 1.107.0, the widely used Python SDK and proxy for LLM providers, was published to PyPI with malware in all seven platform wheels (macOS, Linux, musl Linux and Windows). JFrog, StepSecurity and AISLE each analyzed it. The wheels drop cook.pth, cook.py and sitecustomize.py into site-packages, so the payload runs every time Python starts, even if nothing imports litellm. The sdist and the GitHub tag don't contain the files, so source review missed it.
Stage one steals system info, browser passwords, SSH/GPG/TLS keys, shell history, AWS/GCP/Azure credentials and instance metadata, Kubernetes tokens, CI/CD and AI tool secrets and all environment variables, and posts them encrypted to the lookalike domain www.litellm[.]dev. Stage two forks a background loader that hourly reads a domain from a GitHub dead drop and executes code from it; AISLE found the dead drop empty when it checked. The official litellm/litellm:1.107.0 Docker image, and the mutable latest, main-latest and main-stable tags while they pointed at it, were also affected. StepSecurity says the release was built from a lookalike GitHub repository and that 1.107.0rc1/rc2 and 1.103 to 1.106 wheels it inspected are clean. JFrog calls this the second LiteLLM hijacking of 2026.
Do now: search lockfiles, images and CI logs for 1.107.0; isolate affected hosts; remove the startup files without running the affected Python; rotate every credential the host or CI job could reach; pin 1.106.2 by hash or image digest. Hunting steps are in the hunt item.
Sources: LiteLLM: The attack chain behind the v1.107.0 LiteLLM release (root-cause analysis, Oct 23) · Microsoft Security Blog: Inside the LiteLLM 1.107.0 supply chain compromise (Oct 23) · JFrog: LiteLLM Hijacked Again · StepSecurity analysis · AISLE: found 3 minutes after release · LiteLLM issue #47826 (community tracking)