Litellm
LiteLLM's Poisoned Release Had a Valid Signature
On 21 October LiteLLM 1.107.0 reached PyPI at 11:39 UTC with a credential stealer in all seven wheels, and the v1.107.0, latest, main-latest and main-stable Docker tags followed at 11:46; PyPI pulled it at 13:23, GHCR by 13:51, Docker Hub by 14:20, about 49,000 downloads in between. LiteLLM's own release workflow built, signed and published it from the lookalike repo Berri-AI/litellm, and the cosign signature over the malicious image is still in Rekor (entry 3355443881, 11:47:52 UTC), made with the cosign.pub at commit 0112e53 that the release notes told users to pin; it verifies with openssl today, so a key-pinned cosign verify passed the stealer, while only the SLSA provenance named the wrong source repo. The payload was a 12-byte .pth file plus sitecustomize.py in site-packages, so it ran on every Python start; in a benign reproduction python -I, -s, -E and pip itself all ran the hook, only -S did not, and pip uninstall removed the files (they are in RECORD) while running the hook once more and leaving the forked loader process alone. Python 3.15, released 9 October, deprecated executable .pth lines but still runs them. LiteLLM rotated the signing key on 23 October; the 1.103.8, 1.104.6, 1.105.4 and 1.106.3 releases of 24 October are signed with the new key. The attack chain: a master key committed to the public LiteLLM-Labs/lite-harness repo on 27 May, flagged for revocation and never revoked, used on 10 October against GET /api/v1/managed_agents/agents?limit=100, which returned an org owner's unscoped GitHub CLI OAuth token in the agent configuration; two more maintainer tokens were exfiltrated from CI secrets to webhook.site within 45 minutes.
Marco Kotrotsos·7 Nov 2026·8 min read