LiteLLM Supply-Chain Compromise: What the Credential Exposure Means for Your CI/CD Pipelines

A 40-Minute Window With a Long Tail

In late March, two versions of LiteLLM — a widely used open-source AI gateway — were reportedly available on PyPI for roughly 40 minutes before being quarantined. According to the published incident reports, those versions contained credential-stealing code that collected cloud keys, SSH keys, Kubernetes tokens, database passwords, and other secrets from any environment that installed them, then transmitted the material to an attacker-controlled domain.

LiteLLM identified versions 1.82.7 and 1.82.8 as compromised and advised treating any installation on March 24 up to 16:00 UTC as suspect. The project’s own advisory notes that an unpinned transitive dependency — one pulled in automatically by an agent framework or orchestration tool — could have delivered the compromised package without any team member deliberately choosing it.

That last point is the detail most relevant to security and IT buyers. Whether a team knowingly uses LiteLLM matters less than whether anything on the host installed it.

How Credentials Were Targeted

According to threat intelligence firm CloudSEK, attackers captured roughly 434,000 files from affected systems. The firm assessed that data as mapping to potential exposure across more than 2,500 organizations, though it has been explicit that this figure represents possible exposure rather than confirmed victims.

The malicious package used a Python path configuration file to execute its payload at interpreter startup — meaning it ran whenever any Python process started in the environment, not only when LiteLLM was explicitly imported. Unit 42’s analysis noted the payload specifically read environment variables holding model API keys, including values associated with major AI providers.

The incident is part of a broader supply-chain campaign linked to Aqua Security’s Trivy scanner, tracked by Google as UNC6780 and listed as CVE-2026-33634 in CISA’s Known Exploited Vulnerabilities catalog. According to published accounts, a PyPI publishing token exposed through the compromised Trivy dependency was subsequently used to upload the malicious LiteLLM releases. CloudSEK described this as different stages of the same attack chain rather than competing explanations.

The FBI issued an advisory noting that affiliated actors are likely to weaponize credentials exfiltrated during this campaign well after the initial compromise — specifically calling out CI/CD secrets, publishing tokens, and cloud credentials as targets requiring immediate credential rotation.

Why Static, Long-Lived Secrets Amplify the Risk

The bureau’s guidance is deliberately scoped to credentials rather than to the package itself, and for good reason. A static cloud key, SSH key, or publishing token copied during the exposure window remains fully usable unless it has since been rotated or revoked. Time elapsed since the incident does not reduce that risk.

This incident illustrates several structural weaknesses that identity and access security programs are designed to address:

• Long-lived secrets in CI/CD environments — service accounts and non-human identities holding persistent cloud credentials are high-value targets in any supply-chain attack. Short-lived, scoped tokens significantly reduce the blast radius.
• Secrets management gaps — environment variables are a common but fragile way to pass sensitive values. A dedicated secrets management solution limits what any single process or pipeline can read.
• Lack of least-privilege on runner environments — CI runners that accumulate broad access to cloud accounts, container registries, and database credentials become attractive targets precisely because compromising one yields many usable secrets.
• Unpinned dependencies — packages pulled in without version pinning or integrity verification can change silently, which is how a transitive dependency becomes an unexpected attack vector.

Checkmarx confirmed that credentials obtained through the Trivy attack enabled unauthorized access to its GitHub repositories. Mercor said it was affected by the malicious LiteLLM versions. CERT-EU assessed with high confidence that a European Commission AWS account was compromised through the same supply-chain attack, with a significant volume of data reportedly exfiltrated.

Immediate Steps for Affected Organizations

For teams assessing their exposure, the published advisories converge on a consistent set of actions:

• Audit installations: Check whether LiteLLM 1.82.7 or 1.82.8 was present in any environment during the March 24 window from 10:39 to 16:00 UTC.
• Rotate broadly, not narrowly: Any secret accessible from an affected environment — cloud credentials, database passwords, SSH keys, publishing tokens — should be rotated regardless of whether misuse has been confirmed. Both LiteLLM and CloudSEK explicitly recommend rotating rather than waiting for evidence of active exploitation.
• Search for campaign indicators: The FBI lists repositories named tpcp-docs or docs-tpcp as indicators of compromise. Aqua’s advisory notes the malware used a tpcp-docs- prefix and tagged stolen data as release assets, so exact-name searches may miss variants.
• Move toward short-lived credentials: Both the FBI and Aqua advised teams to replace long-lived tokens with temporary credentials wherever CI/CD workflows allow it.

For organizations that rely on a password or secrets vault — such as Keeper Secrets Manager — this incident is a practical test of whether non-human identities in your pipelines are actually covered by the same rotation and audit disciplines applied to human accounts. The credentials most at risk here were not passwords in a browser; they were machine identities and service account secrets sitting in environment variables, largely invisible to conventional identity governance programs.

The broader lesson from this campaign is that software supply-chain risk is fundamentally a credential-security problem. The initial foothold matters, but the lasting damage depends entirely on what secrets were reachable from the compromised environment — and whether those secrets were rotated before they could be used.

We break down three more energy breaches that began the same way, and the exact access gap behind each, in our Blind Spot Brief for energy.

Reporting: Source