TeamPCP Attack day 6 Backdoors LiteLLM: Your AI Gateway Just Became the Attack Vector

Executive Summary

Between March 19 threat actor TeamPCP compromised Aqua Security’s and March 23 2026 (disclosed by Paul McCarty). Today is day 6, and a new attack appears from the alliance with LAPSUS. This is becoming one of the major compromises in the supply chain.

Executive Summary

On March 24, 2026, two malicious versions of LiteLLM were published to PyPI. LiteLLM is one of the most widely deployed AI infrastructure packages in the Python ecosystem, with over 95 million monthly downloads and adoption by organisations including Stripe, Netflix, and Google ADK. Versions 1.82.7 and 1.82.8 contain a three-stage credential stealer attributed to TeamPCP, the threat actor behind the Trivy and Checkmarx supply chain compromises that have been escalating since late February 2026.

The payload harvests SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes secrets, database passwords, CI/CD tokens, cryptocurrency wallets, and environment variables. In Kubernetes environments, it deploys privileged pods to every node in the cluster and installs a persistent systemd backdoor that polls checkmarx[.]zone for additional payloads every 50 minutes. Version 1.82.8 is particularly dangerous: it uses a Python .pth file that executes the stealer on every Python process startup, regardless of whether LiteLLM is ever imported.

The attack was almost certainly enabled by stolen credentials from the Trivy CI/CD compromise. LiteLLM uses Trivy as its security scanner. When the compromised Trivy action ran in LiteLLM’s pipeline, it harvested the PyPI publishing token. TeamPCP then used that token to publish backdoored packages directly to PyPI, bypassing GitHub entirely. PyPI quarantined the entire project within approximately three hours. The damage window was short, but for a package with LiteLLM’s download volume, three hours is enough to reach thousands of environments.

TL;DR for Engineering Teams

What it is: Supply chain compromise of LiteLLM versions 1.82.7 and 1.82.8 on PyPI, injecting a three-stage credential stealer with Kubernetes lateral movement and persistent backdoor. Attributed to TeamPCP with high confidence. No CVE assigned.

Where it bites: Any Python environment with litellm==1.82.7 or litellm==1.82.8 installed. Version 1.82.8 fires on every Python process startup via a .pth file, not just when LiteLLM is imported. CI/CD pipelines, Kubernetes clusters, cloud workloads, and developer machines are all in scope.

Why it matters: LiteLLM has 95M+ monthly PyPI downloads and handles LLM API keys by design. The stealer harvests 50+ credential paths including AWS Secrets Manager contents and SSM parameters. In Kubernetes, it deploys privileged pods to every node and installs persistence that survives reboots. The credential theft chain continues: Trivy was compromised, which compromised LiteLLM, and stolen credentials from LiteLLM environments will fuel the next wave.

Patch status: Both versions removed from PyPI. Entire litellm project quarantined pending review. Last known-clean version: litellm 1.82.6 (published March 22, 2026).

Immediate action: Check installed version. Uninstall 1.82.7/1.82.8 immediately. Remove persistence artifacts (~/.config/sysmon/, pgmon.service, node-setup-* pods). Rotate every credential accessible to the affected host. Block models.litellm[.]cloud and checkmarx[.]zone.

Vulnerability Overview

Technical Anatomy

Why LiteLLM Was the Perfect Target

LiteLLM is an LLM API gateway. It routes requests across 100+ LLM providers through a single interface. By design, it handles API keys for OpenAI, Anthropic, Google, Azure, and dozens of other providers. A compromised LiteLLM installation does not just expose infrastructure credentials; it exposes the API keys of every LLM provider the organisation uses. For TeamPCP, this is a target-rich environment with maximum credential density per compromised host.

The attack vector was almost certainly the Trivy CI/CD compromise. LiteLLM’s own CI/CD pipeline runs Trivy as its vulnerability scanner. When the compromised Trivy action executed in LiteLLM’s pipeline during the March 19-20 exposure window, it harvested pipeline secrets including the PyPI publishing token. TeamPCP then used that token to push malicious packages directly to PyPI. The timeline fits: Trivy compromised March 19, attacker regains access March 22, LiteLLM packages appear March 24 at 10:39 UTC.

Two Injection Vectors, One Payload

The two affected versions use different delivery mechanisms, and understanding this matters for determining whether your environment was hit.

Version 1.82.7 embeds the payload directly in litellm/proxy/proxy_server.py. The attacker inserted 12 lines at line 128, between two unrelated legitimate code blocks. The injection executes at module import time, meaning any process that imports litellm.proxy.proxy_server triggers the stealer. The malicious code was not present in the upstream GitHub repository; the injection was performed during or after the wheel build process. The attacker also regenerated the RECORD file with the SHA-256 of the backdoored file, so standard integrity checks against the wheel’s own metadata pass cleanly.

Version 1.82.8 adds a second, far more dangerous vector. A file named litellm_init.pth (34,628 bytes) is placed at the wheel root. Python has a feature most developers never think about: any .pth file in site-packages is executed automatically by site.py when the Python interpreter starts. Not when you import the package. Not when you call a function. Every time Python runs. Scripts, notebooks, CI jobs, background services, cron tasks. If litellm 1.82.8 is installed in the environment, the stealer fires whether or not your code ever touches litellm. The .pth launcher uses subprocess.Popen to run the payload in a detached background process, so it does not delay Python startup or produce visible output.

Stage 1: The Credential Harvest

The payload decodes to a 332-line Python orchestrator that unpacks a credential harvester and a persistence dropper. The harvester performs a systematic sweep of the compromised host. The scope is exhaustive:

The harvester also implements a full AWS SigV4 signing routine to authenticate API calls directly to Secrets Manager and SSM Parameter Store using credentials obtained from EC2 Instance Metadata Service. This goes beyond reading files on disk; the stealer actively queries cloud APIs to pull secrets that only exist in managed services.

Stage 2: Encrypted Exfiltration

Collected data is encrypted with AES-256-CBC using a randomly generated session key derived via PBKDF2 from 32 random bytes. The session key is wrapped with a hardcoded RSA-4096 public key using OAEP padding. Both files are bundled into tpcp.tar.gz and POSTed to models.litellm[.]cloud via HTTPS with the header X-Filename: tpcp.tar.gz. The domain is designed to look like legitimate LiteLLM infrastructure (the real domain is litellm.ai). Only the holder of the RSA private key can decrypt the exfiltrated archive. Even if you captured the network traffic, the contents are unreadable without TeamPCP’s key.

Stage 3: Kubernetes Lateral Movement and Persistence

For environments running Kubernetes, the payload escalates significantly. If a Kubernetes service account token exists at /var/run/secrets/kubernetes.io/serviceaccount/token, the harvester enumerates all nodes in the cluster and deploys a privileged pod to each one. Each pod runs in kube-system, uses alpine:latest, requests privileged: true with hostPID and hostNetwork access, mounts the entire host root filesystem at /host, and tolerates all taints so it schedules on every node including control-plane nodes. The pod uses restartPolicy: Never to avoid leaving long-running evidence.

Each pod chroots into the host filesystem and installs the persistence dropper as a systemd user service. The dropper lives at ~/.config/sysmon/sysmon.py with a corresponding systemd unit at ~/.config/systemd/user/sysmon.service, disguised as a ‘System Telemetry Service.’ After a 5-minute initial delay, it enters a loop that polls checkmarx[.]zone/raw every 50 minutes. Each cycle fetches a URL from the C2, compares it against a local state file at /tmp/.pg_state, and checks for the kill switch (if the response contains ‘youtube.com,’ execution aborts). If the URL is new and the kill switch is not engaged, the dropper downloads a binary to /tmp/pglog, makes it executable, and runs it in a detached session. This gives TeamPCP the ability to push arbitrary second-stage payloads to every compromised node at any time.

Core Behaviours: What Makes This Attack Different

The .pth File: Execution Without Import

The most significant technical innovation in this attack is the use of a .pth file for payload delivery. Most Python supply chain attacks require the victim to import the malicious package. The litellm_init.pth file bypasses that requirement entirely. Python’s site.py processes .pth files in site-packages at interpreter startup. If your environment has litellm 1.82.8 installed, the stealer runs every time Python starts. Running pytest? Stealer fires. Launching a Jupyter notebook? Stealer fires. A cron job invoking any Python script? Stealer fires. This is functionally equivalent to a rootkit that hooks the interpreter itself.

Security Tools as Attack Vectors

TeamPCP has now exclusively compromised security-adjacent software: Trivy (vulnerability scanner), KICS (IaC analyser), and LiteLLM (LLM proxy that handles API keys). These tools run with elevated privileges by design. They need broad access to scan, analyse, or proxy. Compromising them is maximally efficient because the attacker inherits the trust the organisation has already granted to the tool. Your vulnerability scanner ran the payload that stole the token that backdoored your AI gateway. The irony is structural, not incidental.

Credential Chain Propagation

Each compromised environment yields credentials that unlock the next target. The February Trivy breach yielded a GitHub org-wide PAT. The March 19 Trivy action compromise harvested CI/CD secrets from thousands of pipelines. Those secrets included npm tokens (enabling CanisterWorm), Docker Hub credentials (enabling poisoned container images), and PyPI publishing tokens (enabling this LiteLLM compromise). Credentials stolen from LiteLLM environments will fuel whatever comes next. Wiz’s head of threat exposure summarised it accurately: the open source supply chain is collapsing in on itself.

The Payload Development History

An operational security failure by TeamPCP left two earlier iterations of the payload as commented-out base64 blobs on lines 131 and 132 of proxy_server.py. Decoding all three reveals the attacker’s development progression. Iteration 1 used exec() and RC4 obfuscation for shell commands, but the same C2 infrastructure and credential targets were already present. Iteration 2 was transitional, carrying both the old RC4 version (commented out) and the new plaintext harvester. Iteration 3, the active payload, removed exec() and RC4 in favour of subprocess piping and tempfile. The C2 endpoints, encryption scheme, persistence mechanism, and credential scope remained identical across all three versions. Only the delivery and evasion mechanisms evolved.

Affected Versions

LiteLLM (This Compromise)

Aqua Security / Trivy Ecosystem (Upstream Compromise)

Checkmarx Ecosystem

npm / CanisterWorm

Discovery and Disclosure Timeline

Determine If You’re Affected

Exposure by Environment

Verification Steps

1. Check installed version: pip show litellm 2>/dev/null | grep Version
2. Search for .pth file: find “$(python3 -c ‘import site; print(site.getsitepackages()[0])’)” -name “litellm_init.pth” 2>/dev/null
3. Check lock files: grep litellm requirements.txt poetry.lock uv.lock Pipfile.lock 2>/dev/null
4. Search for persistence: ls -la ~/.config/sysmon/sysmon.py ~/.config/systemd/user/sysmon.service /tmp/pglog /tmp/.pg_state 2>/dev/null
5. Check Kubernetes: kubectl get pods -n kube-system | grep node-setup
6. Review network logs for connections to models.litellm[.]cloud and checkmarx[.]zone
7. Check systemd: systemctl –user status sysmon.service 2>/dev/null
8. Audit BerriAI org packages: any package published through the same CI/CD infrastructure should be treated as suspect

Detection Guidance

Indicators of Compromise

File Hashes (SHA-256)

Remediation and Temporary Protections

Immediate Actions

1. Identify affected systems: pip show litellm | grep Version across all environments. Check lock files for pinned 1.82.7 or 1.82.8.
2. Uninstall immediately: pip uninstall litellm. Remove litellm_init.pth from site-packages.
3. Kill persistence: systemctl –user stop sysmon.service && systemctl –user disable sysmon.service. Remove ~/.config/sysmon/ and ~/.config/systemd/user/sysmon.service. Kill /tmp/pglog processes. Remove /tmp/pglog and /tmp/.pg_state.
4. Block C2 at network/DNS: models.litellm[.]cloud and checkmarx[.]zone.
5. Kubernetes cleanup: kubectl get pods -n kube-system | grep node-setup and delete. Check all nodes for persistence at /root/.config/sysmon/.
6. Rotate everything: SSH keys, AWS/GCP/Azure credentials, LLM API keys, database passwords, Docker registry tokens, CI/CD secrets, npm/PyPI tokens, Kubernetes secrets, Vault tokens. Every credential accessible on the affected host is compromised.
7. Audit cloud access logs: Check AWS CloudTrail, GCP Audit Logs, and Azure Activity Log for unauthorised access using potentially stolen credentials.

Long-Term Hardening

Pin dependencies to exact versions and verify package integrity against the upstream source repository, not just the registry’s own RECORD hashes. The attacker regenerated the RECORD file, so standard wheel integrity checks pass. Source-to-artifact comparison is the only reliable detection method.

Enable PyPI Trusted Publishers (OIDC-based publishing) to eliminate long-lived API tokens from CI pipelines. If a pipeline does not need a PyPI token, do not give it one.

Pin all GitHub Actions to full SHA commit hashes. The Trivy compromise that enabled this attack propagated through mutable version tags. Tools like Zizmor, pinact, StepSecurity secure-repo, and Renovate with pinGitHubActionDigests automate this.

Restrict IMDS access from containers using IMDSv2 with hop limits. The stealer actively queries EC2 IMDS for role credentials and uses them to pull Secrets Manager and SSM Parameter Store contents.

Implement a delay before adopting new package versions. Community detection of supply chain attacks typically occurs within hours to days. A 48-72 hour hold for non-critical updates provides a meaningful detection window.

Phoenix Security Recommendations

The LiteLLM compromise is the latest proof that vulnerability management must extend beyond CVE scanning. This attack had no CVE, no CVSS score, and no NVD entry. The compromised package was a security-adjacent tool that handles secrets by design. If your vulnerability management programme only flags known CVEs, this attack was invisible to it.

Attack surface management: Phoenix identifies which environments have LiteLLM installed and maps installed versions against the known-compromised 1.82.7 and 1.82.8 releases. For organisations running LiteLLM across development, staging, and production environments, Phoenix provides a single view of exposure rather than per-environment manual audits.

Reachability analysis: Phoenix distinguishes between environments where litellm 1.82.7 or 1.82.8 was installed and where those versions actually executed during the exposure window. An environment with the package installed but never started during the three-hour window has a different risk profile than one running active LLM proxy traffic.

Ownership attribution: Map each affected deployment to the owning team. When LiteLLM is deployed across multiple teams’ infrastructure, coordinated response requires knowing who owns what. Phoenix maps vulnerable components to responsible teams automatically.

References

ReversingLabs – Checkmarx OpenVSX Extension Compromise

Endor Labs – TeamPCP Isn’t Done: Threat Actor Behind Trivy and KICS Compromises Now Hits LiteLLM’s 95 Million Monthly Downloads on PyPI

JFrog Security Research – Popular litellm Python package is the latest victim of TeamPCP’s ongoing supply chain attack

The Hacker News – TeamPCP Backdoors LiteLLM Versions 1.82.7-1.82.8 Likely via Trivy CI/CD Compromise (Ravie Lakshmanan)

LiteLLM GitHub Issue #24512 – Community tracking of compromise

Wiz Research – Trivy Compromised by TeamPCP (wiz.io)

Wiz Research – KICS GitHub Action Compromised: TeamPCP Supply Chain Attack (wiz.io)

Socket Security – CanisterWorm: npm Publisher Compromise Deploys Backdoor Across 29 Packages

Aikido Security – TeamPCP Deploys CanisterWorm on NPM Following Trivy Compromise

Sysdig TRT – TeamPCP Stealer Detected in Checkmarx ast-github-action

Aqua Security – Trivy Supply Chain Attack: What You Need to Know (aquasec.com)

Aqua Security GitHub Security Advisory GHSA-69fq-xp46-6×23

CrowdStrike – From Scanner to Stealer: Inside the trivy-action Supply Chain Compromise

StepSecurity – Trivy Compromised a Second Time: Malicious v0.69.4 Release

Snyk – Trivy GitHub Actions Supply Chain Compromise

How Phoenix Security Fixes What Actually Matters

Your team doesn’t have a finding problem. They have a fixing problem.

Most platforms hand you a list. Phoenix hands you a plan — ranked by real risk, mapped to the team that owns it, with a clear path to close it.

What remediation looks like with Phoenix:

• One backlog, not five. Findings from SAST, SCA, containers, and cloud — deduplicated, correlated, and surfaced in a single prioritized queue. No more reconciling lists across tools.
• Ownership that sticks. Team attribution and inheritance mean the right ticket goes to the right engineer, first time. No routing, no guessing, no back-and-forth.
• Campaigns that move the needle. Group related findings into targeted remediation campaigns. Track progress, measure closure rates, and report real reduction — not raw counts.
• AI that does the legwork, not the deciding. Phoenix’s Remediator agent drafts fixes, creates tickets, and opens PRs. Your team reviews, approves, and merges. Every fix is traceable.

Phoenix Security changes the game.

The results are clear:

• Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
• ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
• IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
• Optimizely has been able to act on vulnerabilities sitting on the backlog.

The pattern is the same every time: teams that move from find and report to analyze and fix close more risk with less effort.

The results are clear:

• Bazaarvoice saved $6.3M in developer time and for teams removed critical in the first weeks of adoption
• ClearBank cut critical container vulnerabilities by 96–99% and reclaimed 4 hours per engineer per week.
• IAS saved an equivalent of 1.5M in development hours and reduced SCA-to-container noise by 82.4%
• Optimizely has been able to act on vulnerabilities sitting on the backlog.

👉 Book a demo today

Or learn how Phoenix Security slashed millions in wasted dev time for fintech, retail, and adtech leaders.

Fix with remediaiton don’t chase ghost vulnerabilities

Get Fixing today