Overview
Two trojanised releases of LiteLLM — an open-source AI gateway widely used to route requests across multiple LLM providers — were published to PyPI on 24 March 2026 and remained available for approximately 40 minutes before the package registry quarantined them. Versions 1.82.7 and 1.82.8 carried credential-stealing code capable of harvesting environment variables, cloud access keys, SSH private keys, Kubernetes service account tokens, and database passwords from any system that installed them. LiteLLM advises treating any installation performed on that date up to 16:00 UTC as suspect.
Threat intelligence firm CloudSEK subsequently obtained a dataset of roughly 434,000 files captured by the attackers and assessed as belonging to the campaign. Its analysis maps potential exposure to more than 2,500 organisations, including NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens, and X Corp. CloudSEK has published the data as a public searchable lookup with high- and medium-confidence confidence tiers. A high-confidence match requires the organisation’s own domain to appear alongside host identity signals in the captured CI runner environment; repository namespaces alone earn only medium confidence.
Technical Analysis
The primary persistence and execution mechanism was a file named litellm_init.pth bundled inside version 1.82.8. Python processes .pth files in site-packages at interpreter startup — meaning the malicious code executed whenever any Python process launched in the affected environment, irrespective of whether LiteLLM was imported. This is a particularly effective technique in CI/CD contexts where Python interpreters are invoked continuously across many jobs.
The payload was designed to enumerate and exfiltrate:
- Environment variables (including
AWS_ACCESS_KEY_ID,GITHUB_TOKEN, etc.) - SSH private keys from
~/.ssh/ - Kubernetes service account tokens from
/var/run/secrets/ - Cloud provider credential files (
.aws/credentials, application default credentials) - Database connection strings
All collected material was staged and transmitted to attacker-controlled infrastructure. The 40-minute exposure window on a heavily downloaded package was sufficient to seed thousands of CI runs across the global developer ecosystem.
Framework Mapping
- AML.T0115 – Publish Poisoned AI Artifacts: Attackers directly injected malicious code into a legitimate LLM-infrastructure package distributed via PyPI.
- AML.T0010 – AI Supply Chain Compromise: LiteLLM occupies a strategic position in AI/LLM deployment pipelines, making it a high-value supply chain target.
- AML.T0083 – Credentials from AI Agent Configuration: Stolen credentials included tokens and keys used to authenticate AI workloads and agent runtimes.
- LLM05 – Supply Chain Vulnerabilities: The attack exploited trust in a widely used open-source LLM middleware package.
- LLM06 – Sensitive Information Disclosure: Exfiltrated secrets directly expose downstream AI infrastructure and cloud environments.
Impact Assessment
Exposure is broad rather than deep in the confirmed sense: CloudSEK’s dataset establishes that files were taken from systems attributable to 2,500+ organisations, not that credentials were used. However, the FBI’s July 2026 advisory (FLASH-20260702-01) explicitly warns that affiliated actors in the linked TeamPCP campaign are likely to weaponise exfiltrated credentials long after initial compromise. Long-lived static secrets — cloud IAM keys, SSH keys, publishing tokens — remain fully valid unless rotated, meaning the attack surface persists months after the original incident.
Mitigation & Recommendations
- Rotate all secrets immediately: Any cloud API key, SSH private key, Kubernetes token, or CI/CD publishing token that could have been present in a Python environment on 24 March 2026 should be revoked and reissued regardless of confirmed exploitation.
- Scan for litellm_init.pth: Check
site-packagesdirectories across all build agents and developer workstations for this file and remove it. - Pin and verify package versions: Use hash-pinned dependencies (
pip install --require-hashes) and verify checksums against known-good releases. - Adopt short-lived credentials: Migrate CI/CD pipelines to OIDC-based ephemeral tokens (e.g., GitHub Actions OIDC with AWS, GCP, or Azure) to limit blast radius of any future supply chain compromise.
- Monitor for credential abuse: Enable anomaly detection on cloud accounts for access from unexpected IP ranges or unusual API call patterns.