CloudSEK’s latest look at the LiteLLM incident has pushed the possible scale of the breach much higher. Data reconstructed from the wider TeamPCP and Trivy campaign points to environments linked with more than 2,500 organizations, although that number does not mean 2,500 organizations were definitely compromised.

The March incident involved malicious LiteLLM packages uploaded to PyPI. Researchers now say the campaign data contains about 434,000 captured files and exfiltration-related records, but those records should not be mistaken for 434,000 separate CI/CD pipelines.

A captured file can roughly line up with a job execution, which makes the raw total useful for showing volume, not for counting unique victims. The safer way to read the data is to separate captured records, possible executions, attributed organizations, and confirmed compromises.

LiteLLM says versions 1.82.7 and 1.82.8 were published on March 24, 2026, starting at 10:39 UTC, and were available for around 40 minutes. PyPI’s later incident report gives a longer timeline, recording 2 hours and 32 minutes between the initial malicious upload and quarantine. The malicious code targeted credentials and other sensitive data, while LiteLLM’s investigation points back to the Trivy dependency used in its CI/CD security scanning workflow.

On March 19, 2026, attackers used compromised credentials to publish a malicious version of Trivy 0.69.4. Trivy is widely used to scan software and development environments for security issues, including within CI/CD workflows.

That access also put credentials and other sensitive secrets within reach. The incident was not limited to LiteLLM, but formed part of a wider software supply chain campaign that spread through trusted development tooling, underscoring why organizations need continuous supply chain penetration testing to uncover hidden third-party risks.

Trivy GitHub Actions Were Also Compromised:

The attackers also altered the GitHub Actions connected to Trivy, giving the campaign another route into trusted workflows. NIST says 76 of 77 version tags in aquasecurity/trivy-action were force-pushed to credential-stealing code, while all seven tags in aquasecurity/setup-trivy were replaced with malicious commits.

That mattered because many CI/CD workflows call GitHub Actions by version tag. If an attacker changes the code behind that tag, the workflow file can look the same while running different code in the background, making the compromise much harder to notice.

The Trivy compromise became relevant to LiteLLM because Trivy was part of its CI/CD security scanning process. PyPI’s incident report says an API token was exposed through the exploited Trivy dependency, after which malicious LiteLLM releases were published to PyPI.

The sequence was simple: Trivy was compromised, the publishing credential was exposed, and malicious LiteLLM releases followed. PyPI’s incident report confirms the token exposure, but it does not establish that LiteLLM’s legitimate GitHub repository itself was poisoned.

TeamPCP Linked to the Wider Campaign

The FBI linked the activity to TeamPCP in an alert issued on July 2, 2026. According to the bureau, the group compromised trusted software distribution channels by inserting malicious code into legitimate packages and development dependencies.

The FBI associated the campaign with several components, including:

• Trivy
• LiteLLM
• KICS
• Telnyx Python SDK

That broader pattern matters because LiteLLM was not targeted in isolation. It was one of several trusted tools and dependencies used to reach development environments through software organizations were already relying on.

More Than 119,000 Downloads Recorded: PyPI reported that the compromised LiteLLM versions were downloaded more than 119,000 times before being quarantined. That figure shows how widely the releases were retrieved.

Malicious LiteLLM Releases Targeted Cloud, AI and Developer Secrets

LiteLLM’s investigation found that version 1.82.7 contained malicious code in its AI Gateway proxy component. Version 1.82.8 carried the same code and added a file named litellm_init.pth, which created another path for execution inside affected Python environments.

That second file increased the risk because Python can process .pth files during startup. In other words, the malicious code did not always depend on someone directly calling the compromised LiteLLM functionality, which makes installation history more important during incident review.

The payload was designed to collect a broad range of sensitive information from affected systems. LiteLLM identified environment variables, SSH keys, cloud credentials, Kubernetes tokens and database passwords among the data at risk, while the FBI has separately linked TeamPCP activity to the theft of cloud access tokens, SSH keys and Kubernetes secrets.

That means the exposure was not limited to AI API keys. The exposed data could include cloud credentials, SSH keys, Kubernetes tokens, database passwords, environment variables and other secrets present in the affected runtime. Protecting these environments requires regular cloud security penetration testing to ensure IAM roles, access tokens, and cloud infrastructure remain safe from post-exploitation access.

Removing the malicious package also does not automatically close the incident. Any stolen credential can remain valid until it is rotated or revoked, and the FBI has warned that TeamPCP activity has also involved credential-stealing malware and persistent backdoors.

For organizations running AI infrastructure, the LiteLLM incident shows how valuable the software around a model can be to attackers. Gateways and orchestration tools often sit close to multiple credentials, making them an attractive route into broader development and cloud environments.

Why the LiteLLM Incident Still Matters

The reconstructed dataset also contained records associated with environments linked to NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens and X Corp. Their inclusion does not establish that any of these organizations were breached through LiteLLM or that attackers successfully used credentials connected to them.

Attention has now moved to credentials that could have been copied during the March activity and remained valid afterward. In its July alert, the FBI warned that credentials taken during TeamPCP operations could be used well after the original compromise and recommended replacing exposed secrets, particularly those connected to CI/CD systems, publishing access and cloud services.

LiteLLM’s own guidance asks users to check historical environments for versions 1.82.7 and 1.82.8, including installations introduced indirectly through dependencies. That means an investigation can extend beyond what is currently running in production to previous builds, containers and development environments where one of the affected releases was present.

Remediation and Long-Term Containment

Singapore’s Cyber Security Agency has taken a similarly cautious position on the wider TeamPCP campaign. Its advisory recommends treating secrets available to an affected environment as exposed and rotating them, rather than waiting for evidence that every credential was actually used.

The FBI has also called for stronger control over credentials inside development pipelines, broader logging and integrity checks before software artifacts are published or deployed. Those measures reflect a problem seen throughout this incident: trusted development infrastructure itself became part of the attack path.

What began with the compromise of a security tool ultimately reached another project’s package distribution and then the environments that downloaded those releases. PyPI’s incident report shows how exposed publishing access allowed malicious packages to move through a legitimate software channel, even though the upstream project itself remained recognizable to users.

For organizations reviewing the incident now, removing the malicious package was only one part of containment. Any credential taken before that removal remains a separate security issue until it is revoked or replaced, which is what keeps the LiteLLM compromise relevant months after the poisoned releases disappeared from PyPI.