The Trust Paradox: How a Security Scanner Became the Attack Vector in the "LiteLLM" Compromise
March 28, 2026
On March 24, production systems began experiencing critical failures. Engineers saw runaway processes, CPUs pinned at 100%, containers killed by OOM errors. The stack traces all pointed to LiteLLM, a Python package downloaded roughly 3.4 million times per day, used by organizations like Stripe, Netflix, and Google as a unified gateway to over 100 LLM providers.
The package had been backdoored. And the entry point wasn’t a zero-day, a misconfigured S3 bucket, or a disgruntled insider.
It was the vulnerability scanner!
The Anatomy of a Cascading Supply Chain Compromise
This attack, attributed to the threat actor group TeamPCP and tracked as CVE-2026-33634 (CVSS 9.4), represents one of the most sophisticated multi-ecosystem supply chain campaigns publicly documented to date. It spanned five ecosystems, PyPI, npm, Docker Hub, GitHub Actions, and OpenVSX, in a single coordinated operation. What makes it architecturally interesting is the cascading trust exploitation: each phase weaponized credentials harvested in the previous one.
Let me walk through the kill chain.
This attack, attributed to the threat actor group TeamPCP and tracked as CVE-2026-33634 (CVSS 9.4), represents one of the most sophisticated multi-ecosystem supply chain campaigns publicly documented to date. It spanned five ecosystems, PyPI, npm, Docker Hub, GitHub Actions, and OpenVSX, in a single coordinated operation. What makes it architecturally interesting is the cascading trust exploitation: each phase weaponized credentials harvested in the previous one.
Let me walk through the kill chain.
Phase 1: Compromising the Scanner (Trivy)
Trivy is an open-source vulnerability scanner developed by Aqua Security, integrated into the CI/CD pipelines of thousands of projects via the trivy-action GitHub Action. Security scanners are uniquely dangerous supply chain targets, by design, they require broad read access to environment variables, configuration files, and runner memory.
The initial foothold exploited a misconfigured GitHub Actions workflow. Specifically, a pull_request_target trigger allowed an automated bot (”hackerbot-claw”) to execute arbitrary code within the context of the Trivy repository. This is a well-documented issue: pull_request_target runs workflows with write permissions and access to repository secrets, even when triggered by a fork’s pull request.
The bot exfiltrated a privileged Personal Access Token (PAT) from the CI environment.
Phase 2: Poisoning the Distribution Channel
With the stolen PAT, and later, a compromised aqua-bot service account, the attacker force-pushed malicious commits to 75 of 76 version tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy. They also published a malicious Trivy binary release (v0.69.4) and pushed poisoned images to Docker Hub.
This is the critical insight: anyone referencing these tags by name (e.g., trivy-action@v0.3.5) was now silently pulling attacker-controlled code. The tags resolved to the same string, but the underlying commit had been replaced. Mutable references became payload delivery channels.
Phase 3: Credential Harvesting from LiteLLM’s Pipeline
LiteLLM (BerriAI) used Trivy as part of its CI/CD security scanning, without pinning to an immutable commit hash. When the pipeline executed the now-compromised trivy-action, the injected payload harvested CI/CD secrets from the runner environment, including the PyPI publishing token (PYPI_PUBLISH).
The irony is structural: the more diligent an organization was about running security scans on every build, the greater their exposure window.
Phase 4: Trojanized Package Distribution
Using the stolen PyPI credentials, TeamPCP published two malicious versions of litellm, v1.82.7 and v1.82.8, directly to PyPI, bypassing the project’s normal release process.
Version 1.82.8 was particularly notable for its execution mechanism. It embedded a malicious .pth file (litellm_init.pth) in site-packages/. The .pth mechanism fires on every Python interpreter startup, no import required. Every python, pip, or pytest invocation would trigger the credential stealer. The .pth file was correctly declared in the wheel’s RECORD file with a matching SHA-256 hash, so pip install --require-hashes would have passed. The package cleared all standard integrity checks because the malicious content was published using legitimate credentials.
PyPI quarantined the malicious packages within approximately three hours. But with 3.4 million daily downloads, the exposure window was significant.
What the Payload Exfiltrated?
The credential stealer was comprehensive. Two variants were deployed, one optimized for CI/CD runner environments (harvesting from process memory and environment variables), and a second, more generic stealer targeting the local filesystem. Data exfiltrated included:
SSH private keys (~/.ssh/) and Git credentials
Cloud provider credentials (AWS, GCP, Azure tokens and config files)
Kubernetes secrets and service account tokens
API keys and environment variables (.env files, shell profiles)
Slack, Discord, and other messaging tokens
CI/CD configurations and pipeline secrets
Shell history and auth logs from /var/log/auth.log
System metadata: hostname, environment variables, running processes, network routing tables
Data was exfiltrated to an attacker-controlled domain (models[.]litellm.cloud) with a fallback exfiltration channel to public GitHub repositories, a clever choice, since GitHub traffic looks routine in engineering environments. Persistence mechanisms also referenced a secondary C2 domain (checkmarx[.]zone), suggesting shared infrastructure across the campaign’s phases.
MITRE ATT&CK Framework Mapping
This attack chain maps cleanly across multiple ATT&CK tactics and techniques. Here is how each phase of the operation aligns:
Why This Attack Was Structurally Inevitable
The fundamental issue is not that TeamPCP was unusually sophisticated, though their operational tempo was impressive (six days from initial compromise to five ecosystems breached). The issue is that the modern CI/CD ecosystem is built on layers of implicit trust that compound into systemic fragility.
Three specific architectural failures enabled this campaign:
Mutable references as trust anchors. Pointing to a Git tag like trivy-action@v0.3.5 instead of a specific commit SHA (e.g., trivy-action@a1b2c3d4) means a force-push silently replaces trusted code with arbitrary content. The reference looks identical. The content is entirely different. This is not a novel observation, but the industry has collectively failed to internalize it.
Security tools as privileged attack surface. Vulnerability scanners, IaC analyzers, and LLM gateways require broad access to secrets by design. Trivy scans your images, so it sees your environment. LiteLLM routes your LLM traffic, so it holds every provider’s API key. Compromising any one of these tools gives the attacker everything the tool was trusted to touch.
Credential concentration in AI infrastructure. LiteLLM is particularly devastating as a target because a typical deployment stores API keys for OpenAI, Anthropic, Azure OpenAI, Google Vertex AI, AWS Bedrock, and others in a single location. Wiz Research found LiteLLM present in 36% of the cloud environments they monitor. One compromised package, and every model, every provider, and every API key is exposed.
Here's a timeline visualization of the breach cascade and discovery
Public Sources and Further Reading
Trend Micro Research: Your AI Gateway Was a Backdoor: Inside the LiteLLM Supply Chain Compromise (March 2026): https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html
SANS Institute: When the Security Scanner Became the Weapon: Inside the TeamPCP Supply Chain Campaign (March 2026): https://www.sans.org/blog/when-security-scanner-became-weapon-inside-teampcp-supply-chain-campaign
Snyk: How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM (March 2026): Detailed technical walkthrough of the .pth execution mechanism and the T1546.018 mapping. https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/
ReversingLabs: TeamPCP Software Supply Chain Attack Spreads to LiteLLM (March 2026): Payload analysis, attribution, and expert commentary on cascading CI/CD trust failures. https://www.reversinglabs.com/blog/teampcp-supply-chain-attack-spreads
Arctic Wolf: TeamPCP Supply Chain Attack Campaign Targets Trivy, Checkmarx (KICS), and LiteLLM (March 2026): Enterprise impact assessment and remediation guidance.
GitGuardian: Trivy’s March Supply Chain Attack Shows Where Secret Exposure Hurts Most (March 2026): Analysis of credential exposure patterns and incomplete remediation.
Mend.io: TeamPCP Supply Chain Attack Part 2: LiteLLM PyPI Credential Stealer (March 2026): Indicators of compromise and detection strategies.
https://www.mend.io/blog/teampcp-supply-chain-series-part-2/
LiteLLM Official: Security Update: Suspected Supply Chain Incident (March 2026): Maintainer disclosure, Mandiant engagement, and verified clean versions.