LiteLLM says attackers used an unrevoked internal master key, stolen GitHub OAuth tokens and compromised release workflows to publish a malicious version of its Python package, turning a secret-management failure into a software supply-chain attack. The poisoned litellm==1.107.0 package was available on PyPI for roughly two hours on October 21, while affected Docker and GitHub Container Registry images were also published. LiteLLM’s root-cause analysis says the attacker was not attributed to a named group or country. [1][3]
The intrusion began with a configuration file committed to the public LiteLLM-Labs/lite-harness repository on May 27 that contained the master key for an internal LiteLLM Agent Platform deployment. Although the commit was later overwritten, the key was not revoked. LiteLLM says the attacker used it on October 10 from the IP address 69.48.229.143 to access the platform and extract a GitHub CLI OAuth token associated with an organization owner.
That token gave the attacker a path into private repositories and release automation. According to LiteLLM, throwaway workflows exfiltrated additional GitHub tokens and secrets to an attacker-controlled webhook.site endpoint. The attacker then bypassed branch protections, redirected the release process to the lookalike Berri-AI/litellm repository, and used a second stolen token to approve the production release. The resulting artifacts were built from attacker-controlled commit 20535d8f, rather than the official source tree.
The affected PyPI package was live from approximately 11:39 to 13:23 UTC on October 21, and all seven published wheels were affected. LiteLLM also identified compromised Docker Hub and GHCR tags including v1.107.0, latest, main-latest and main-stable. The vendor says the package contained compiled malware capable of stealing credentials and loading remote-code-execution tools; affected Python environments executed files including cook.pth and sitecustomize.py when Python started. [3]
Users who installed litellm==1.107.0 or ran the affected container tags during those windows should treat the host as compromised, even if the malware’s filesystem markers are absent. LiteLLM recommends rebuilding affected environments, removing the malicious files and detached process, and rotating every secret reachable from the host, including cloud roles, provider keys, database credentials and LiteLLM master or virtual keys. The vendor’s explicitly recommended rollback is litellm==1.106.2; enterprise customers using the private enterprise registry were not affected according to the incident report.
LiteLLM quarantined the PyPI release, removed or repointed Docker tags and made affected GHCR tags unavailable. The incident reports do not identify a CVE, CVSS score or public proof of concept, and they do not establish downstream exploitation beyond the compromise of LiteLLM’s own release pipeline. They also say the initial access method remains unconfirmed, although the company suspects a recently patched vulnerability may have exposed its internet-facing internal deployment. [1][3]
References
- The attack chain behind the v1.107.0 LiteLLM release
- Contained: Oct 21, 2026 LiteLLM release v1.107.0 …
