LiteLLM added signed Docker images and a private release repository after its first supply chain breach. Attackers got in anyway, and the project’s own pipeline signed the malware for them. That is the uncomfortable lesson here, and it reaches well beyond one open-source gateway.
According to CSO Online, version 1.107.0 of LiteLLM went out through PyPI and official Docker images on October 21. The malicious Python packages stayed up for about two hours. The Docker images, including those under the latest, main-latest and main-stable tags, were pulled or replaced later that day. Anyone who grabbed those tags in the window is exposed.
The payload is nasty. Per security firm Aikido, files in the package ran automatically when Python started, even if the application never imported LiteLLM. The malware collected cloud credentials and the API keys stored in LiteLLM’s database. It also targeted Kubernetes service account tokens and secrets for CI/CD systems like GitLab and Jenkins. A remote access trojan added a background process that fetched and ran code from attacker infrastructure every hour.
LiteLLM’s incident report says attackers used stolen GitHub credentials from three developer accounts to alter the release workflow and point it at a lookalike repository. The credentials may have leaked from logs on an internet-facing internal deployment. The company also noted that Claude Code could expose GitHub tokens in responses that LiteLLM then logged. How the attackers first reached that deployment is still unknown. Customers on the private enterprise registry were not affected.
This is the second compromise this year. In March, malicious LiteLLM packages shipped after a breach the project tied to the Trivy scanner in its release process. The fix was reasonable on paper: private repository, signed images. But a signature only proves an artifact hasn’t changed since signing. It says nothing about whether the code was safe when signed. If the attacker controls the workflow, they control the signature.
Why this matters: an AI gateway sits in the middle of everything. Teams use LiteLLM, like alternatives such as Portkey or OpenRouter-style proxies, to route requests across model providers from one place. That is convenient and good for governance. But as IDC’s Sakshi Grover put it, centralizing access “concentrates trust.” A compromised gateway holds provider keys, cloud credentials and often a path into the build system. Keith Prabhu of Confidis said it gives hackers a strong foothold and exposes far more than AI API keys.
The cleanup advice is blunt. Removing the package is not enough, because the trojan can persist. Prabhu recommends isolating suspected systems, preserving forensic evidence, rebuilding from trusted software, and rotating every secret the deployment could reach. Grover adds a practical warning: don’t launch Python or pip in a suspect environment, since the startup hooks could fire again. She also suggests correlating AI usage telemetry with cloud and identity audit logs, though a careful attacker may keep token spend quiet.
The longer-term fixes are less glamorous. Verifiable build provenance, pinned package and image digests in production, independent approval for any change to release workflows, and tighter protection of publishing credentials. Most teams pulling open-source AI tooling into production don’t do all of that today.
Is this noise? No. Two incidents in one year at a widely deployed project, with a credential stealer aimed at the exact secrets AI platforms accumulate, is a pattern. If you run LiteLLM, check your image digests today. If you build on any fast-moving AI dependency, assume the release pipeline is part of your attack surface.
