LiteLLM Hack Exposes Secrets From 2,488 Companies Across 118,829 CI Runner Dumps

The LiteLLM supply-chain compromise has shifted from a short-lived malicious package incident into a sprawling enterprise exposure event.

Analysis of an alleged 153GB attacker archive has linked 118,829 CI runner dumps to 2,488 corporate domains, exposing the depth of secrets accessible inside modern build environments.

The campaign, publicly attributed to TeamPCP, began upstream of LiteLLM. Attackers first compromised the GitHub Actions ecosystem around Trivy, the widely used open-source vulnerability scanner.

Snyk’s incident analysis places the malicious uploads at 10:39 UTC and 10:52 UTC, respectively; PyPI quarantined them roughly three hours later.

This was not conventional dependency poisoning. Version 1.82.7 embedded malicious code in LiteLLM’s proxy server path, while 1.82.8 added a litellm_init.pth startup hook.

The latter was particularly dangerous because Python processes .pth files whenever the interpreter initializes.

As a result, the payload could execute without an explicit LiteLLM import, including during routine Python, pip, or automated CI activity.

Trend Micro’s technical breakdown describes the rapid 13-minute shift from application-level execution to interpreter-level activation.

The malware was designed to harvest the data CI runners routinely hold: environment variables, cloud credentials, SSH keys, Kubernetes tokens, Docker registry logins, source-control credentials, .env files, database configuration, and AI-provider API keys.

Hudson Rock Researchers said that, LiteLLM’s CI/CD pipeline consumed the poisoned Trivy action, allowing the adversary to harvest a PyPI publishing token from the runner environment and publish trojanized litellm versions 1.82.7 and 1.82.8 on March 24, 2026.

Encrypted collected data before exfiltration and included mechanisms for local persistence and Kubernetes lateral movement.

LiteLLM Hack Exposes Secrets

The code’s presence does not prove every capability was successfully exercised against every victim, but it demonstrates that a compromised runner could become a launch point for deeper cloud and cluster compromise.

Hudson Rock says its raw-data analysis attributed 118,829 dumps to 2,488 organizations, while CloudSEK reported a broader dataset of more than 2,500 potentially exposed companies and approximately 434,000 CI/CD pipeline records.

These figures should be interpreted as exposure intelligence rather than proof that every listed organization suffered confirmed downstream intrusion or credential abuse.

The reported corpus allegedly includes records associated with major global enterprises across technology, telecommunications, manufacturing, financial services, and cloud infrastructure.

Yet victim attribution is difficult. A developer email address may identify an employer, while internal CI hosts, registries, and self-hosted GitLab endpoints can point to a subsidiary, supplier, or entirely separate operational entity.

Security teams should therefore prioritize infrastructure markers, runner metadata, repository ownership, and cloud audit evidence over surface-level identity fields.

For defenders, removal of the affected packages is not sufficient. Any system that installed or executed LiteLLM 1.82.7 or 1.82.8 should be treated as a potential credential-exposure incident.

Teams should investigate package inventories, runner logs, outbound traffic, persistence artifacts, cloud control-plane activity, Kubernetes audit events, and package publishing histories.

All secrets accessible to affected runners especially cloud keys, CI tokens, GitHub or GitLab credentials, registry credentials, and LLM API keys should be revoked and rotated.

The incident reinforces a hard lesson for AI infrastructure: gateways such as LiteLLM aggregate privileged access by design.

A single poisoned dependency can expose not just an application, but the identity, deployment, cloud, model-routing, and production-control layers surrounding it.

CloudSEK’s exposure report also warns that stolen credentials can remain useful long after malicious package versions disappear, making sustained post-incident hunting essential.

[Live Webinar] Join Elastic & UnderDefense to learn how small security teams can unify AI visibility and agentic response into one operating model. -> Register Now