# LiteLLM 1.107.0 Was Backdoored: The Python .pth Trick That Stole Keys Before the Library Even Loaded

> On 21 October 2026, malicious LiteLLM 1.107.0 artifacts hit PyPI, Docker Hub and GHCR. The payload ran at Python startup via a .pth file — no import needed — and exfiltrated cloud, AI, SSH and GPG credentials to a look-alike domain. What happened, the IOCs, and exactly what a security team should do now.

Source: https://playciso.com/blog/litellm-1-107-0-supply-chain-compromise-credential-stealer · Published: 2026-10-21 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://docs.litellm.ai/blog/security-incident-oct-21-2026

---

On 21 October 2026, one of the most widely deployed open-source LLM gateways was turned into a credential stealer for about two hours. Malicious **LiteLLM 1.107.0** artifacts were published to **PyPI, Docker Hub and GHCR**, and the payload did something worth every security team’s attention: it ran **at Python startup, before LiteLLM was ever imported**, and shipped your cloud, AI, SSH and GPG keys to a look-alike domain. This is the second supply-chain hit on LiteLLM in 2026, and the mechanism is a clean teaching case. _Independent, docs-grounded analysis for security & engineering leaders, based on LiteLLM’s official advisory and GitHub issue plus corroborating research (Socket, Wiz, Endor Labs, Upwind, The Hacker News). PlayCISO is not affiliated with LiteLLM/BerriAI. We name no individual as the attacker — the project is the victim of a pipeline compromise; the investigation into the entry vector is ongoing._ The incident in plain words **What:** malicious `litellm==1.107.0` wheels (all seven) on PyPI, plus Docker Hub/GHCR images tagged `v1.107.0`, `latest`, `main-latest`, `main-stable`. Published ~04:40 PDT, detected ~06:32 PDT, removed shortly after. **How:** a **build-pipeline compromise**, not a source change — the official v1.107.0 git tag is clean; the bad wheels were built from an attacker-controlled repository. **Payload:** a `cook.pth` file that executes at Python interpreter startup (no import of litellm required), stealing cloud credentials, AI provider keys and SSH/GPG keys and exfiltrating to the look-alike `www.litellm.dev` (official project is `litellm.ai`); a loader/backdoor for further code was also reported. ## The clever, nasty part: execution without import Most people reason about dependency risk as "the code runs when I call it." The `.pth` mechanism breaks that assumption. Python processes `.pth` files in `site-packages` during interpreter startup, and any line starting with `import` is executed immediately. By dropping a `cook.pth`, the attacker guaranteed the stealer fired **the instant any Python process started** in that environment — a cron job, a health check, a totally unrelated script — whether or not anything ever imported `litellm` or started the proxy. "We installed it but never used it" is therefore _not_ a safe position for this incident. It is the same lesson as malicious npm `postinstall` scripts: installation itself is code execution. ## Why the pipeline, not the code The public source for v1.107.0 was fine. The artifacts were not. That gap — trusted Git tag, poisoned published wheel — is the signature of a release-pipeline compromise, and it is exactly why signing and provenance matter: if your build emits signed artifacts with verifiable provenance (who built it, from which commit, on what runner), a wheel built from an attacker-controlled repo fails verification before it ever reaches a developer or a container. Reproducible builds and pinned, hash-verified dependencies close the same gap from the consumer side. ## What a security team should do now - Pin to v1.106.2 — the last release before the compromised one — and hash-pin it. - Find exposure. Any pip install litellm==1.107.0 or pull of the affected image tags in the window (~04:40–06:40 PDT / ~11:40–13:40 UTC on 21 Oct; floating Docker tags lagged the takedown, so treat slightly later pulls as suspect) is in scope. - Rebuild, do not just uninstall. The .pth may have already executed, so an in-place uninstall does not restore trust — rebuild the host or container from clean, verified sources. - Rotate everything the environment could read: cloud provider keys, AI provider API keys, SSH and GPG keys, and any LiteLLM proxy master key. Treat them as exposed, not "possibly exposed." - Hunt the IOCs: researchers cite the files /tmp/.pc_once_* and /tmp/remote_code_loader.lock, and outbound connections to www.litellm.dev. Egress monitoring would have flagged that exfiltration domain — a reminder that default-deny egress on build and inference hosts is a real control, not a nicety. ## The standing lesson for AI platform teams AI tooling has become critical path, and it carries the same supply-chain risk as any other dependency — arguably more, because gateways and proxies sit on top of your most sensitive secrets (every model key, every cloud credential). The durable defenses are unglamorous and they work: pull from a **vetted private registry** (the enterprise deployments doing this were unaffected here), **pin and hash-verify** versions, require **artifact signing and provenance**, keep an **inventory of what you actually run**, and put **egress controls** around build and inference hosts so a stealer cannot phone home. This was LiteLLM’s second supply-chain incident of the year; the teams who treated the [first one](/blog/litellm-supply-chain-attack-teampcp-what-to-do) as a system to fix, not a one-off, had far less to do this morning. ## Put it to work We build free tools around exactly these controls: - Release Pipeline Integrity Scorecard — score your build/release pipeline against the weaknesses this incident exploited (provenance, signing, reproducibility, registry trust). - AIBOM generator — an AI Bill of Materials so you actually know which services run which AI components and versions when the next advisory drops. - Context from the earlier hit: The LiteLLM TeamPCP attack, and the pipeline-integrity angle from the OVHcloud CLI compromise. Follow the [official LiteLLM advisory](https://docs.litellm.ai/blog/security-incident-oct-21-2026) and [GitHub issue #47826](https://github.com/BerriAI/litellm/issues/47826) for the authoritative, continuously-updated remediation steps and the ongoing root-cause investigation.