A signed package is not a safe package. That is the uncomfortable lesson from LiteLLM, the open-source AI gateway that was hit by its second supply chain attack this year, after the maintainers had already tightened their release process.
The malicious version, 1.107.0, reportedly went out through PyPI and official Docker images on October 21. The Python packages stayed up for about two hours. The Docker images, including the latest, main-latest and main-stable tags, were pulled or replaced later that day. If your deployment grabbed those tags in the window, you have a problem.
Aikido, the security firm that analyzed the package, says bundled files ran automatically when Python started. Your app did not even need to import LiteLLM. The malware hunted for cloud credentials and API keys stored in LiteLLM’s database, and it went after Kubernetes service account tokens and CI/CD secrets for systems like GitLab and Jenkins. It also dropped a remote access trojan that phoned home every hour for new code. So removing the package does not remove the attacker.
How did they get in? LiteLLM says attackers used stolen GitHub credentials from three developer accounts to alter the release workflow and redirect it to a lookalike repository. The company suspects the credentials leaked from logs on an internet-facing internal deployment. It also found cases where Claude Code could expose GitHub tokens in responses that LiteLLM then logged. Still, the initial access to that deployment is unexplained. That is a big gap in an incident report.
The detail that should worry you most is the signing. After the March compromise, which the project tied to the Trivy scanner in its pipeline, LiteLLM moved releases to a private repository and added signed Docker images. The attackers simply modified the workflow, which then signed and published the malware itself. A valid signature proves an artifact was not changed after signing. It says nothing about whether the code was clean beforehand. Vendors love to sell signing as a trust guarantee. It is not one.
Why does this matter for privacy? An AI gateway sits in front of every model, prompt and key your organization uses. IDC’s Sakshi Grover put it plainly: centralizing access can improve governance, but it also concentrates trust. Keith Prabhu of Confidis said a compromised gateway offers a strong foothold well beyond AI API keys. Add in IDC’s finding that 95% of surveyed enterprises have at least one agent-enabled workflow in production, and the blast radius is obvious. Prompts, customer data and cloud access can all sit behind one compromised service.
LiteLLM says the incident is contained and that customers on its private enterprise registry were unaffected. Its advice for everyone else is to assume breach and rotate exposed credentials. The experts agree, and add some practical steps:
- Find every deployment, developer machine and CI runner that pulled the affected packages or image digests.
- Do not launch Python or pip on suspect systems, because the startup hooks could fire again.
- Isolate machines and preserve forensic evidence before rebuilding from trusted software.
- Rotate every secret the deployment could reach, including cloud and pipeline credentials.
- Pin production to verified digests and require independent approval for release workflow changes.
Grover also suggests correlating AI usage telemetry with cloud and identity audit logs. Odd token spikes can signal misuse, though careful attackers may keep spending quiet. And she warns that missing indicators do not prove an environment is clean.
The broader trend is hard to miss. Attackers no longer need to break your code. They target the people and pipelines that ship it, and AI tooling is fast becoming a rich target. If your build process trusts a single set of maintainer credentials, you are one leaked log away from this story.