---
title: LiteLLM 1.107.0 backdoored on PyPI and in official Docker images: credential stealer plus hourly remote-code loader runs on every Python start | ctxsec
url: https://ctxsec.com/items/litellm-1-107-0-pypi-docker-backdoored-wheels
description: "All seven litellm 1.107.0 wheels (published Oct 21 around 11:40 UTC) and the official litellm 1.107.0 Docker images carried a credential stealer and an hourly remote-code loader. PyPI has removed the release. Treat any host that installed it as compromised and rotate everything it could reach."
status: "confirmed (JFrog, StepSecurity and AISLE research; PyPI release removed); LiteLLM root-cause analysis published Oct 23 (leaked, never-revoked Agent Platform key led to an org owner's GitHub token), last updated Oct 25, 2026, 8:10 PM ET"
published: 2026-10-21
updated: 2026-10-25T20:10:00-04:00
---

> All seven litellm 1.107.0 wheels (published Oct 21 around 11:40 UTC) and the official litellm 1.107.0 Docker images carried a credential stealer and an hourly remote-code loader. PyPI has removed the release. Treat any host that installed it as compromised and rotate everything it could reach.

[← Cybersecurity News](/news) · [markdown](/items/litellm-1-107-0-pypi-docker-backdoored-wheels.md)

confirmed (JFrog, StepSecurity and AISLE research; PyPI release removed); LiteLLM root-cause analysis published Oct 23 (leaked, never-revoked Agent Platform key led to an org owner's GitHub token)

2026-10-21 · updated

Oct 25, 2026, 8:10 PM ET

### 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](https://research.jfrog.com/post/litellm-hijacked-again/), [StepSecurity](https://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealer) and [AISLE](https://aisle.com/blog/litellm-11070-on-pypi-shipped-a-credential-stealer) 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](/hunting#hunt-litellm-1-107-0-cook-pth-iocs).

Sources: [LiteLLM: The attack chain behind the v1.107.0 LiteLLM release (root-cause analysis, Oct 23)](https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain) · [Microsoft Security Blog: Inside the LiteLLM 1.107.0 supply chain compromise (Oct 23)](https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/) · [JFrog: LiteLLM Hijacked Again](https://research.jfrog.com/post/litellm-hijacked-again/) · [StepSecurity analysis](https://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealer) · [AISLE: found 3 minutes after release](https://aisle.com/blog/litellm-11070-on-pypi-shipped-a-credential-stealer) · [LiteLLM issue #47826 (community tracking)](https://github.com/BerriAI/litellm/issues/47826)
