An unrevoked key opened the door to LiteLLM’s poisoned release
3-line summary
- LiteLLM’s October 23 investigation identified an unrevoked master key as the entry point.
- The October 21 release carried malicious startup hooks absent from its source archive.
- Affected artifacts were removed; the advisory calls for rebuilding compromised environments and rotating credentials.
LiteLLM traced its poisoned release to an exposed, unrevoked key in its October 23 investigation. The Agent Platform master key appeared publicly on May 27. Overwriting the commit left the key usable when the attacker accessed the platform on October 10.
The affected release was 1.107.0 on October 21. LiteLLM lists exposure windows of 11:39–13:23 UTC for PyPI and 11:46–14:20 UTC for Docker Hub. Tags including latest also referenced it. The company says its separate private enterprise registry was unaffected.
LiteLLM is an open-source gateway connecting applications to multiple AI providers through one interface. Provider credentials stay at the gateway, while applications and users receive virtual keys with budgets and rate limits. The service also records the cost of requests passing through it.
The experimental Agent Platform filed GitHub pull requests. LiteLLM says the attacker took its stored owner-level GitHub CLI credential, then obtained two engineers’ credentials through CI. The final report corrects the suspicion that deployment logs supplied the first credential.
Datadog identified three stolen identities used to launch, approve and erase build records. Berri-AI/litellm, one hyphen away from the genuine repository, became the source. Legitimate publication channels distributed the malicious artifacts, with provenance recording that substitution.
JFrog found three extra files in all seven platform wheels, absent from the source archive. Timestamps and metadata favored inclusion during wheel construction over later manual repacking. Source-archive review alone could miss executable content in the installable package. JFrog identified a credential collector and a separate remote loader.
Python’s documentation describes startup processing of import lines in .pth files and the sitecustomize module. These mechanisms normally run before application code, regardless of whether a particular library will be used. JFrog found that the malicious files exploited these hooks, executing without an application importing LiteLLM.
Datadog identified collection of cloud, developer, AI-tool and browser credentials. On a configured LiteLLM proxy, the malware also queried database tables holding upstream provider credentials. Upstream AI services were among the targets.
The loader checked hourly for a location to fetch further code. Datadog reported only test values in that lookup file and no second-stage payload observed in the wild. That observation does not negate the collector’s separate credential-stealing function.
LiteLLM removed affected artifacts or redirected tags to clean builds. Its advisory says package-folder removal alone leaves startup hooks behind. The response guidance covers rebuilding affected environments and rotating credentials reachable from them, including provider keys stored in the proxy database.
Sources
- October 23 — causal investigation — LiteLLM
- October 21 — scope and response advisory — LiteLLM
- Independent wheel and startup-hook analysis — JFrog Security Research
- Independent credential and loader analysis — Datadog Security Labs
- Gateway and credential model — LiteLLM Docs
- Interpreter startup hooks — Python Docs
Corrections
- Clarified the wording for GitHub access credentials.
- Fixed a Korean grammar typo introduced while clarifying access credentials.
