LiteLLM Supply-Chain Attack Exposed Credentials at 2,500+ Orgs

A supply-chain attack on LiteLLM, an open-source tool widely used to simplify AI-driven software development, exposed terabytes of credentials from more than 2,500 organizations. Security firms CloudSEK and Hudson Rock disclosed the incident on Tuesday and Wednesday this week, revealing that attackers had poisoned a version of LiteLLM on the Python Package Index (PyPI) repository. The compromise lasted just 40 minutes in March, but that was enough to steal cloud keys, SSH keys, Kubernetes secrets, and AI provider credentials from organizations including Microsoft, Amazon, Cisco, Samsung, and Salesforce.

What happened

Detail	Fact
Tool targeted	LiteLLM (open-source AI development library)
Attack vector	Compromised package on Python Package Index (PyPI)
Compromise window	40 minutes, in March 2025
Data volume analyzed	195 TB file obtained by Hudson Rock
Organizations affected	More than 2,500
Named organizations	Microsoft, Amazon, Cisco, Samsung, Salesforce
Disclosures published	CloudSEK and Hudson Rock, Tuesday and Wednesday this week

LiteLLM is a popular open-source library that lets developers route requests across multiple large-language-model providers from a single interface. Its wide adoption in AI development pipelines made it a high-value target: anyone who installed the poisoned version from PyPI (Python’s official package repository) during that 40-minute March window handed attackers a direct line into their environment.

According to CloudSEK, the stolen material includes cloud provider keys, source-code repository tokens, SSH keys (cryptographic credentials used for secure server access), Kubernetes secrets (configuration data used to manage containerized applications), package publishing credentials, environment variable files, and keys for AI API providers. Any one of those credential types could give an attacker persistent access to internal systems.

Why does a 40-minute window cause this much damage?

The attack window sounds short, but PyPI is an automated supply chain. Developers and CI/CD pipelines (automated build and deployment systems) pull packages the moment a new version is published. A malicious package sitting in an official repository for even a brief period can be installed thousands of times before anyone notices.

Neither CloudSEK nor Hudson Rock publicly identified the person or group behind the attack, according to both firms’ disclosures. Hudson Rock reached its findings by obtaining and analyzing a 195TB file containing the exfiltrated data.

Why it matters

This incident sits at the intersection of two fast-moving trends: the rapid adoption of AI development tooling and the ongoing vulnerability of open-source software supply chains. Teams integrating AI into their products are pulling in new dependencies quickly, often without the same security scrutiny applied to longer-standing libraries.

The credential types exposed here are particularly dangerous. AI provider API keys can run up enormous bills or be used to exfiltrate proprietary data sent through those APIs. Cloud keys can expose entire infrastructure environments. Kubernetes secrets can give an attacker control over production workloads. SSH keys can provide persistent server access that survives password resets.

For businesses using AI integration services or building in-house AI tooling, this is a reminder that the dependency chain matters as much as the code you write yourself. If your team is using LiteLLM or any similar multi-provider routing library, auditing your installed versions and rotating credentials should be an immediate priority.

We covered a similar trust-and-training concern recently when Twitch updated its AI data policies, but this attack is more operationally severe: it is active credential theft, not a policy change.

Our take

The 40-minute window is the detail that should worry security teams most. It means the attacker understood exactly how automated package consumption works and timed the attack to maximize installs before detection. This is not opportunistic. It is deliberate, precise, and it worked against some of the largest technology companies in the world.

For smaller businesses, the lesson is not that you are necessarily a direct target. The lesson is that you are almost certainly downstream of organizations and tooling that are. If your developers use Python-based AI libraries and your credential rotation policy is “when we remember to,” this incident is a reasonable reason to change that today.

CloudSEK’s finding of more than 2,500 affected organizations also suggests the blast radius here is still being mapped. Expect more disclosures as firms work through the 195TB dataset.

What to do about it

1. Check your installed version of LiteLLM and compare it against the official changelog to identify whether the compromised version was ever present in your environment.
2. Rotate all credentials that were accessible in environments where LiteLLM ran during March: cloud keys, AI provider API keys, SSH keys, repository tokens, and Kubernetes secrets.
3. Audit your PyPI dependencies more broadly. Tools like pip-audit can flag known-malicious or vulnerable packages.
4. Lock package versions in your build system using a pinned requirements file or a lock file, and verify package hashes at install time.
5. Set up alerts for unusual API usage on your cloud and AI provider accounts so credential abuse is caught quickly even if rotation is delayed.

Credential hygiene is not optional for teams shipping AI products. If you need help auditing your stack, the Lumien team can walk through your environment with you via our contact page.

Source: Ars Technica · AI