A LiteLLM compromise has raised concern over how a trusted AI software component can become an entry point into a network. The supply chain incident placed build systems, cloud accounts and source code at risk, although the malicious releases were available for only about 40 minutes.

The campaign began after attackers compromised the release process for the Trivy scanner. LiteLLM’s build pipeline installed that tool without locking it to a verified version, allowing poisoned code to enter the build and produce malicious LiteLLM packages on PyPI.

CloudSEK analysts identified the activity as part of a campaign attributed to TeamPCP. Its reconstructed dataset linked more than 2,500 organizations and 434,000 CI/CD pipeline runs to the affected path, but exposure does not prove every organization was breached.

A malicious Python startup file could run when Python started, instead of when an application imported LiteLLM. The payload could then collect credentials available to developer workstations and build runners, including cloud keys, repository tokens and AI service keys.

CloudSEK said in a report shared with Cyber Security News (CSN) that copied credentials may remain useful long after package removal. The incident shows why a brief package compromise can create a response effort.

LiteLLM Supply Chain Attack

The malicious LiteLLM releases were published after the compromised Trivy component reached the project’s build environment. The incident carries the risk of trusted package supply chain attacks: one altered dependency can reach environments before maintainers react.

On a CI/CD runner, the credential-stealing payload sought elevated access and searched for SSH keys, cloud credentials, Kubernetes tokens, environment files and secrets in process memory.

It also targeted LLM API keys and gateway settings, creating a route to connected AI systems and valuable sensitive data in those environments.

Researchers said data was encrypted before being sent to a typosquatted destination. When transfer failed, the malware could create a public repository in the victim’s GitHub account and upload material as a release asset.

That makes the exposure harder to spot because the apparent source is the victim’s account. The company names in the dataset need handling.

CloudSEK described them as high-confidence exposure matches, not confirmation of malicious execution, data theft or attacker use. Organizations should validate whether the package was downloaded, cached or executed, rather than assume either compromise or safety.

What Defenders Should Do Next

Teams should identify installations of the affected versions and isolate related runners, hosts, container images and caches. They should rotate every credential available to the affected process, not only the LiteLLM or model-provider key.

Recent compromised PyPI package incidents show how cloud, registry and source-control tokens can turn one package incident into a wider breach.

Affected environments should be rebuilt from known-clean sources. Teams should review cloud, source-control, package registry and Kubernetes audit records for unusual token use, new service accounts, suspicious outbound connections and unexpected repositories.

Searches should cover the period after removal, since stolen access can be reused later. For prevention, CloudSEK recommends pinning dependencies and GitHub Actions to verified hashes, reducing credential lifetime and scope, and using workload identity instead of static keys where possible.

This aligns with advice following GitHub Actions security changes, where safer workflow design limits damage from untrusted code. AI systems deserve attention because they often sit between sensitive data, cloud services, and tools that can perform actions.

Maintaining an inventory of AI assets and owners, watching third-party dependencies and monitoring build-time behavior can reduce blind spots. The lesson mirrors the recent CI backdoor campaign: trusted automation is valuable to defenders, but also to attackers.

For organizations with production credentials in the affected build path, the report’s message is clear: rotate high-value secrets before waiting for conclusive evidence. The disruption of a planned rotation is usually less severe than an attacker retaining access to code, infrastructure or customer data.

Indicators of compromise (IoCs):-

Type	Indicator	Description
Malicious package versions	LiteLLM 1.82.7, LiteLLM 1.82.8	Affected PyPI releases identified in the supply chain incident
Malware	SANDCLOCK	Credential-stealing payload associated with compromised CI/CD runners
File type	`.pth`	Malicious Python startup file used for automatic execution
File path	`/proc/`	Process memory path reportedly scraped for CI/CD secrets
GitHub repositories	`tpcp-docs`, `docs-tpcp`	Unexpected repositories highlighted for threat-hunting activity

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Stop new phishing & malware before they compromise your business. Integrate live intel from 15K SOCs around the world

The post LiteLLM Supply Chain Attack Potentially Exposes 2,500 Companies and 434,000 CI/CD Pipelines appeared first on Cyber Security News.