A major software supply chain breach involving LiteLLM has reportedly exposed credentials, cloud keys, API tokens, and internal configuration data from thousands of enterprise CI/CD environments.
Forensic investigations by Snyk, Trend Micro, and Cycode show that LiteLLM was not the initial target.
The attack reportedly began when threat actor TeamPCP compromised the GitHub Actions pipeline associated with Trivy, a widely used open-source vulnerability scanner.
LiteLLM developers used Trivy in their own CI/CD workflow. This gave the compromised scanner legitimate access to the LiteLLM runner environment.
Attackers allegedly used that access to steal PyPI publishing tokens, then used the tokens to release malicious LiteLLM package versions 1.82.7 and 1.82.8.
The malicious releases used a Python .pth startup hook. This technique allowed the payload to run automatically when Python started, even if an application did not directly import the LiteLLM library.
Such execution makes the attack particularly dangerous because affected developers and automated pipelines may not immediately notice suspicious behavior.
LiteLLM Breach Steals CI/CD Credentials
The multi-stage payload reportedly collected environment variables and searched for local configuration files. Targeted files included Kubernetes configuration data such as .kube/config and cloud credentials including .aws/credentials.
CI/CD environments commonly contain high-value secrets because they automate software builds, cloud deployments, container publishing, testing, and infrastructure changes.
GITLAB_USER_EMAIL variable, directly attributing the leaked pipelines to major global organizations like Orange, Boeing, and Roku (Source: hudsonrock)A single compromised runner may contain source-control tokens, package repository keys, cloud access credentials, internal API secrets, database passwords, and deployment certificates.
Researchers said the payload also attempted lateral movement through Kubernetes environments and installed a persistent systemd backdoor. This could allow attackers to retain access after the initial CI/CD job ended.
Hudson Rock stated that it obtained a 153GB RAR archive containing 433,909 files linked to the incident. Its analysis reportedly identified 118,829 CI runner dumps associated with 2,488 corporate domains.
The dataset allegedly includes raw environment dumps collected from affected developer systems, production servers, and CI/CD pipelines.
The exposed data reportedly contains GitLab variables, AWS access keys, Azure secrets, Slack signing secrets, Salesforce client secrets, internal JWTs, NPM tokens, Bitbucket deployment tokens, Elastic API keys, and AI-provider API keys.
AWS_SECRET_ACCESS_KEY and environment-specific secrets like WORKLOADS_DEV_AWS_SECRET, dumped in plain text (Source: hudsonrock)Exposure of AI-provider keys may enable attackers to access LLM infrastructure, consume paid API quotas, or inspect workflows that use AI routing services.
Attributing a leaked CI/CD environment to the correct organization is not always straightforward.
Committer email addresses alone can be misleading because contractors, subsidiaries, shared services, and third-party platforms may appear in pipeline records, hudsonrock said.
One example reportedly involved a committer email using the @siriusxm.com domain.
However, infrastructure indicators such as CI_SERVER_FQDN=gitlab.adswizz.com and registry.adswizz.com suggested that the affected environment belonged to AdsWizz, a SiriusXM subsidiary.
Analysts should therefore prioritize infrastructure markers, internal hostnames, registry domains, and cloud account identifiers when identifying affected organizations.
Detect, investigate, and respond faster with in-browser data inspection from ANY.RUN. Gain complete phishing visibility to strengthen your SOC and reduce MTTR
