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

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 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 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 and GitHub issue #47826 for the authoritative, continuously-updated remediation steps and the ongoing root-cause investigation.