A 40-Minute Blitz Attack with Lasting Consequences
On March 24, 2026, two hacked versions of LiteLLM — an open-source AI gateway widely used to connect applications to multiple model providers — were available on PyPI for about 40 minutes, between 10:39 and 11:25 UTC. The exposure time seems trivial, but the consequences have stretched over months. On August 12, 2026, the threat intelligence company CloudSEK revealed that it had obtained a dataset consisting of approximately 434,000 files captured by the attackers, mapping a potential exposure affecting more than 2,500 organizations, including NVIDIA, Cisco, Deloitte, Volkswagen, FedEx, Siemens, and X Corp.
Essential clarification: this number is not a count of victims. CloudSEK explicitly clarifies to The Hacker News: the material comes from confidential intelligence sources and consists of files and exfiltration logs assessed as belonging to the campaign, and not data collected from the named organizations. The dataset is published as a public research table, searchable by name or domain, with filtering by confidence level (High or Medium).
The TeamPCP Attack Chain, from Trivy Scanner to LiteLLM
The LiteLLM incident can only be understood by tracing back to the supply chain compromise campaign called TeamPCP (tracked by Google under the name UNC6780). It all starts with Trivy, the security scanner from Aqua Security.
On March 19, 2026, a malicious actor using compromised credentials published a malicious version of Trivy v0.69.4, forced the rewriting of 76 out of 77 version tags of aquasecurity/trivy-action to commits containing a credential thief, and replaced the 7 tags of aquasecurity/setup-trivy with malicious commits. The attack is recorded under the reference CVE-2026-33634, added to CISA's Exploited Vulnerabilities Catalog (KEV) on March 26, 2026.
According to the security advisory published by Aqua Security on GitHub, this incident is a continuation of an initial compromise dating back to late February 2026. After an initial disclosure on March 1, a credential rotation was indeed carried out — but non-atomically. The attackers could have used valid tokens during the rotation window (which lasted several days) to exfiltrate newly regenerated secrets and maintain their access.
On March 22, malicious Trivy v0.69.5 and v0.69.6 Docker images were also published on Docker Hub via separate compromised Docker Hub credentials. On March 23, the KICS GitHub Action from Checkmarx was compromised in turn, following the same modus operandi: same naming conventions, same RSA-4096 public key, as documented by Wiz.
How LiteLLM Was Poisoned
The 1.82.7 and 1.82.8 versions of LiteLLM, published directly on PyPI on March 24, contained a sophisticated credential thief. According to the official incident report from LiteLLM:
- v1.82.7: malicious payload embedded in
litellm/proxy/proxy_server.py, triggered upon importinglitellm.proxy. - v1.82.8: addition of a
litellm_init.pthfile (34,628 bytes) which, like any.pthfile placed insite-packages, is executed by Python at interpreter startup — even if LiteLLM is never imported. The project specifies that a pinned transitive dependency, for example via an AI agents framework or orchestration tool, could install this version without anyone explicitly choosing it.
The malicious payload collected:
- environment variables (including
OPENAI_API_KEYandANTHROPIC_API_KEY) - SSH keys and Git configurations
- cloud credentials (AWS, GCP, Azure)
- Kubernetes tokens and service account configurations
- database passwords
- cryptocurrency wallets
- SSL private keys, shell history, CI/CD configurations
The data was then encrypted (AES-256-CBC with a random session key, itself encrypted by a hardcoded RSA-4096 public key) and exfiltrated via an HTTP POST to models.litellm[.]cloud — a domain registered on March 23, 2026, via Spaceship, Inc., just a few hours before the appearance of the malicious packages, and with no connection to the LiteLLM project.
A highly detailed technical analysis published by FutureSearch and the rosesecurity.dev blog reveals additional details: a Kubernetes persistence mechanism created privileged pods in the kube-system namespace, while a Python backdoor was installed in ~/.config/sysmon/sysmon.py with a systemd service. A backup exfiltration channel used the available GITHUB_TOKEN to create a public repository named tpcp-docs and upload the stolen data as release assets.
A Disputed Account of the Infection Method
The exact manner in which the malicious versions reached PyPI is subject to divergent narratives:
- CloudSEK claims that a poisoned build produced and published the releases.
- LiteLLM, in its own incident report and in GitHub issue #24518, indicates that a direct upload to PyPI bypassed the official CI/CD workflow, suggesting the compromise of a maintainer's PyPI account (
krrishdholakia). - Unit 42 describes attackers targeting PyPI publish tokens after the Trivy breach.
When questioned by The Hacker News, CloudSEK dismissed the contradiction: “These are different steps of the same attack chain, not competing explanations.” The PyPA's advisories also describe the same sequence: an API token exposed via the compromised Trivy dependency, then used to upload the two versions.
The CloudSEK Dataset: Method and Limits
Attribution in the dataset relies on two independent checks. A first index assigns each file based on the identity variables of the CI runner (host identity, domains of legitimate contributors). A second "property gate" redirects ownership based on recovered logs and can override the first assignment. “If the two are in disagreement, the report is withheld,” states CloudSEK, and the final verdict takes the lowest confidence level.
The figure of 434,000 files counts captured files and exfiltration events rather than distinct pipelines or jobs. CloudSEK specifies that a captured file corresponds approximately to a job execution, but does not present the total as unique jobs without deduplication and independent verification. The company did not wish to comment on the pre-publication notifications sent to the named organizations, nor indicate if any of them disputed their inclusion.
Confirmed Victims Beyond Statistics
Even though CloudSEK's figures remain estimates of exposure, the actual impact of the campaign is confirmed:
- Checkmarx acknowledged that credentials obtained via the Trivy attack allowed unauthorized access to its GitHub repositories and the publishing of malicious artifacts (compromise of the KICS action and OpenVSX extensions).
- Mercor reported being affected by the malicious versions of LiteLLM and containing unauthorized activity.
- CERT-EU assessed with a high level of confidence that an AWS account of the European Commission was compromised via the Trivy attack, with approximately 91.7 GB of compressed data exfiltrated.
The FBI Urges Secret Rotation
In a FLASH notice dated July 2, 2026 (FLASH-20260702-01), the FBI warned that affiliated actors are likely to exploit the exfiltrated credentials from the TeamPCP campaign long after the initial compromise. A long-lived secret copied during the exposure window — a static cloud key, an SSH key, a publish token — remains usable as long as it has not been revoked. The Bureau recommends rotating all CI/CD secrets, publish tokens, and cloud credentials accessible during the relevant exposure windows, and advises prioritizing temporary tokens (OIDC, short-lived credentials) over long-lived tokens.
The Scale of Contamination
The NVD report for CVE-2026-33634 now lists several affected components beyond Trivy and LiteLLM:
| Component | Affected Versions |
|---|---|
| Trivy (Go/image) | = 0.69.4 |
| trivy-action (GitHub Action) | 0.0.1 – 0.34.2 |
| setup-trivy (GitHub Action) | 0.2.0 – 0.2.5 |
| BerriAI LiteLLM | 1.82.7 – 1.82.8 |
| team-telnyx/telnyx (Python) | 4.87.1 – 4.87.2 |
| KICS GitHub Action (Checkmarx) | all tags until March 23 |
| Checkmarx OpenVSX Extensions | cx-dev-assist 1.7.0, ast-results 2.53.0 |
The malicious Trivy v0.69.5 and v0.69.6 Docker images, published on March 22 on Docker Hub, were also compromised via separate Docker Hub credentials.
What Should Concerned Organizations Do?
Three priority steps are recommended by all consulted sources:
-
Check Exposure: look for any installation of LiteLLM 1.82.7 or 1.82.8 during the audit window of March 24, 2026 (10:39 to 16:00 UTC). LiteLLM provides scan scripts for GitHub Actions and GitLab CI. For Trivy, check the workflow logs from March 19-20, 2026, looking for the revealing line
Terminate orphan process: pid (...) (curl). -
Rotate All Secrets: any credential present on affected systems should be considered compromised — SSH keys, cloud credentials, Kubernetes tokens, database passwords, model API keys (OpenAI, Anthropic, etc.).
-
Search for Exfiltration Artifacts: scour the GitHub organizations for repositories named
tpcp-docsordocs-tpcp. The prefixtpcp-docs-may vary and releases are taggeddata-<timestamp>, so an exact name search may fail.
Structural Lessons
The incident illustrates several structural fragilities of the open-source ecosystem: the mutability of Git tags (which are merely movable pointers), the dangers of unpinned transitive dependencies, and the risk of a non-atomic credential rotation leaving access windows for attackers. LiteLLM has since rebuilt its CI/CD pipeline (“CI/CD v2”) with isolated environments, strengthened security gates, and cosign signatures for its Docker images. Aqua Security has enabled immutable releases on GitHub.
But beyond technical fixes, the message from CloudSEK and the FBI is clear: the stolen secrets from March 2026 remain an active currency for attackers. Rotation should not wait for proof of exploitation — it is the default response.