How a Poisoned Security Scanner Became the Key to Backdooring LiteLLM

On March 24, 2026, two versions of the litellm Python package on PyPI were found to contain malicious code. The packages (versions 1.82.7 and 1.82.8) were published by a threat actor known as TeamPCP after they obtained the maintainer's PyPI credentials through a prior compromise of Trivy, an open source security scanner used in LiteLLM's CI/CD pipeline.

The malicious versions were available for approximately three hours before PyPI quarantined the package. LiteLLM is downloaded roughly 3.4 million times per day.

Snyk has been tracking this incident. If you're a Snyk customer, you may have already seen the in-app banner alert and received an email notification. The vulnerability record is SNYK-PYTHON-LITELLM-15762713, and status updates are on the Snyk Trust Center.

TL;DR

Leading events

How it was discovered

Callum McMahon at FutureSearch was testing a Cursor MCP plugin that pulled in litellm as a transitive dependency. Shortly after Python started, his machine became unresponsive due to RAM exhaustion. He traced it to the newly installed litellm package and found litellm_init.pth, a 34,628-byte file in site-packages/, double base64-encoded.

The RAM exhaustion was a side effect of the payload, not an intentional feature. The .pth mechanism fires on every Python interpreter startup. Because the payload spawns a new Python subprocess, and that new process also triggers .pth execution, the result was an unintended fork bomb. McMahon published his findings on futuresearch.ai, and the disclosure spread to r/LocalLLaMA, r/Python, and Hacker News within the hour.

The attack chain

The attack on LiteLLM started five days earlier with Trivy.

March 19: The attackers rewrote Git tags in the trivy-action GitHub Action repository to point to a malicious release (v0.69.4) carrying the same credential-harvesting payload and exfiltration infrastructure used in later operations. (For full details on the Trivy compromise, see Snyk's Trivy GitHub Actions supply chain compromise coverage.)

March 23: The same infrastructure was used in a separate attack on Checkmarx KICS (Keep Infrastructure as Code Secure). The C2 domain checkmarx.zone, which impersonates the Checkmarx security company, was registered and activated in this operation.

March 24: LiteLLM's CI/CD pipeline ran Trivy as part of its build process, pulling it from apt without a pinned version. The compromised action exfiltrated the PYPI_PUBLISH token from the GitHub Actions runner environment. With that credential, the attackers published litellm 1.82.7 at 10:39 UTC and 1.82.8 at 10:52 UTC, each containing malicious payloads.

Initial LiteLLM maintainer response on Hacker News.

Two Delivery Mechanisms

The two malicious versions used different injection techniques:

1.82.7 (source injection): The payload was base64-encoded and embedded directly inside litellm/proxy/proxy_server.py. It executes when anything imports litellm.proxy, the standard import path for LiteLLM's proxy server mode.

1.82.8 (.pth file): This version added litellm_init.pth to site-packages/. The .pth mechanism fires on every Python interpreter startup with no import required, including when pip, python -c, or an IDE's language server starts Python.

The .pth file is correctly declared in the wheel's RECORD file, so it passes pip's hash verification. The package passes all standard integrity checks because the malicious content was published using legitimate credentials, not injected after the fact. Snyk Learn has a detailed walkthrough of how this class of attack works in Compromise of a Legitimate Package.

CPython maintainers have acknowledged the security risk of .pth startup hooks in issue #113659, but no patch has been applied. This technique maps to MITRE ATT\&CK T1546.018 (Python Startup Hooks).

The three-stage payload

Stage 1: Information collection

The script collects:

• System data: hostname, environment variables, running processes, network routing, recent auth logs from /var/log/auth.log

• Credentials: SSH private keys, .env files, Git credentials, API keys from shell history, Slack and Discord webhook tokens, CI/CD configs (Jenkins, Travis CI, Terraform), password hashes from /etc/shadow

• Cloud credentials: AWS credentials and config, GCP and Azure service account files, cloud metadata via direct IMDS queries, AWS Secrets Manager, and SSM Parameter Store (with full IMDSv2 signing implemented in the script)

• Container and orchestration: Docker config.json (registry credentials), Kubernetes kubeconfig files, service account tokens, secrets, and certificates

• Cryptocurrency: Bitcoin, Ethereum, Solana, Cardano, Monero wallet files and seed phrases, Ledger hardware wallet configurations

Portion of the decoded malicious code, showing structured iteration and collection of secrets in various directories

Stage 2: Encryption and exfiltration

Collected data is encrypted before transmission:

1. A 32-byte AES-256 session key is generated via openssl rand

2. Data is encrypted with AES-256-CBC (PBKDF2 key derivation)

3. The session key is encrypted with a hardcoded 4096-bit RSA public key (OAEP padding)

4. Everything is bundled into tpcp.tar.gz

5. The bundle is POST'd to https://models.litellm.cloud/ via curl

models.litellm.cloud is distinct from the legitimate litellm.ai domain and was registered on March 23, one day before the malicious packages were published.

The RSA public key in this payload is identical to the one found in the Trivy and KICS payloads. Wiz researchers confirmed this match across all three operations, making it the strongest single technical attribution link.

Temporary files created during exfiltration: session.key, payload.enc, session.key.enc, tpcp.tar.gz in the system temp directory.

Defanged view of the malicious code. The tpcp.tar.gz archive name is a consistent marker across the Trivy, KICS, and LiteLLM operations.

Stage 3: Persistence and lateral movement

Local persistence:

• Writes a backdoor Python script to ~/.config/sysmon/sysmon.py (or /root/.config/sysmon/sysmon.py)

• Creates a systemd user service at ~/.config/systemd/user/sysmon.service with the description "System Telemetry Service"

• Registers and enables it: systemctl --user daemon-reload && systemctl --user enable --now sysmon.service

The persistence script polls https://checkmarx.zone/raw every 5 minutes for a URL, downloads the file to /tmp/pglog, makes it executable, and runs it as a background process. State is tracked in /tmp/.pg_state. At the time of analysis, the endpoint returns YouTube URLs; the operator can switch to delivering live payloads at will.

Kubernetes lateral movement: If the script finds a Kubernetes service account token at the standard mount path, it reads all secrets across every namespace. It then attempts to deploy a privileged pod to every node in kube-system using alpine:latest. These pods mount the host filesystem and install the sysmon backdoor on the underlying node.

Malicious pods are named node-setup-{node_name} (node name truncated to 35 characters), with a container named setup.

About TeamPCP

TeamPCP (also identified as PCPcat, Persy_PCP, ShellForce, and DeadCatx3 per Wiz Threat Center) has been active since at least December 2025. The actor maintains Telegram channels at @Persy_PCP and @teampcp and embeds the string "TeamPCP Cloud stealer" in payloads. Wiz has tracked the full campaign (Wiz Threat Center; Wiz blog; ramimac.me).

The LiteLLM compromise is Phase 09 of an ongoing campaign. Consistent infrastructure across all operations: same RSA key pair, same tpcp.tar.gz bundle naming, and tpcp-docs-prefixed GitHub repositories used as dead-drop C2 staging. All three domains in this operation share the same registrar (Spaceship, Inc.) and hosting provider (DEMENIN B.V.).

The actor has also deployed CanisterWorm, which uses the Internet Computer Protocol (ICP) as a C2 channel. ICP canisters cannot be taken down by domain registrars or hosting providers. Aikido security researchers document this as the first observed use of ICP as a C2 mechanism in a supply chain campaign.

A component called hackerbot-claw uses an AI agent (openclaw) for automated attack targeting. Aikido researchers documented this as one of the first cases of an AI agent used operationally in a supply chain attack.

Issue suppression

When community members began reporting the compromise in GitHub issue #24512, the attackers posted 88 bot comments from 73 unique accounts in a 102-second window (12:44-12:46 UTC). The accounts used were previously compromised developer accounts, not purpose-created profiles. Rami McCarthy's analysis found 76% account overlap with the botnet used during the Trivy disclosure.

Using the compromised krrishdholakia maintainer account, the attackers closed issue #24512 as "not planned" and made commits to unrelated repositories with the message "teampcp update."

The community opened a parallel tracking issue (#24518) and continued discussion on Hacker News, where the thread reached 324 points.

Confirmed impact

The affected versions were on PyPI for approximately 3 hours. The following projects filed security PRs or issues on March 24 to pin away from 1.82.7 and 1.82.8:

The .pth mechanism fires when any Python process starts, including pip itself. In CI/CD environments, this means the payload can execute during build steps, not just at application runtime.

Detection: Are you affected?

Step 1: Check your installed version

If the output shows 1.82.7 or 1.82.8, treat the system as compromised and follow the remediation below. Do not just upgrade; the payload may have already run.

Step 2: Check for persistence artifacts

Step 3: Check for malicious .pth files

Step 4: Verify file hashes

Step 5: Check for network indicators

Step 6: Check Kubernetes

Step 7: Scan with Snyk

The Snyk in-app banner alert, with affected repositories surfaced in the asset inventory. The Trust Center link navigates to real-time incident status.

Snyk customers can also check the litellm package advisor and the full vulnerability record at SNYK-PYTHON-LITELLM-15762713.

If you have NOT installed 1.82.7 or 1.82.8:

Pin to <=1.82.6 until a clean release is available:

If you HAVE installed 1.82.7 or 1.82.8:

The payload executes when Python starts, including during pip install itself. Treat the system as potentially compromised regardless of whether you ran any application code.

1. Remove persistence artifacts:

1. Rotate credentials on the affected system:

• SSH private keys: generate new keys, revoke old keys from authorized_keys, GitHub, GitLab

• Cloud credentials: AWS access keys, GCP service account keys, Azure service principals

• API keys: .env files, shell environment variables, CI/CD secrets

• Docker registry credentials: ~/.docker/config.json

• Kubernetes: ~/.kube/config, in-cluster service account tokens

• Database passwords from any config files on the system

• Git credentials from ~/.gitconfig or the system credential store

• Cryptocurrency wallet seed phrases

1. Audit AWS Secrets Manager and SSM Parameter Store, as the payload queries these directly if instance metadata is accessible.

1. Audit Kubernetes cluster secrets. If a service account token was present, all secrets across all namespaces may have been read. Check for node-setup-* pods in kube-system.

1. Install a clean version on a fresh environment rather than upgrading in-place:

Why pip hash verification didn't catch this

Hash verification confirms a file matches what PyPI advertised, but does not indicate whether the advertised content is malicious.

The litellm_init.pth file in 1.82.8 is correctly declared in the wheel's RECORD file with a matching hash. pip install --require-hashes would have passed. The package passes all standard integrity checks because the malicious content was published using legitimate credentials; there is no hash mismatch, no suspicious domains, and no misspelled package name.

The only install-time detection path is inspecting whether a package installs .pth files and whether those files contain patterns like subprocess, base64, or exec. No widely deployed pip plugin currently does this automatically.

The broader pattern

The target selection across this campaign focuses on tools with elevated access to automated pipelines: a container scanner (Trivy), an infrastructure scanning tool (KICS), and an AI model routing library (LiteLLM). Each of these tools requires broad read access to the systems it operates on (credentials, configs, environment variables) by design.

LiteLLM is increasingly being deployed as a centralized LLM gateway that stores API credentials for multiple model providers. In that configuration, the credential set accessible from a single compromised host is broader than for a typical application.

The initial disclosure spread through AI developer communities (r/LocalLLaMA, r/Python, Hacker News) rather than through traditional security channels such as r/netsec or CVE feeds.

For further reading on supply chain risks specific to LLM tooling, Snyk Learn covers the topic in Supply Chain Vulnerabilities in LLMs. The Ultralytics AI Pwn Request supply chain attack from 2024 is also a useful comparison case: another widely used AI Python library compromised via a CI/CD exploit, with a similar attack chain.

Indicators of compromise

File hashes:

Network:

• Exfiltration: https://models.litellm.cloud/ (POST)

• C2 polling: https://checkmarx.zone/raw (GET)

Filesystem:

• ~/.config/sysmon/sysmon.py or /root/.config/sysmon/sysmon.py

• ~/.config/systemd/user/sysmon.service (description: "System Telemetry Service")

• /tmp/tpcp.tar.gz, /tmp/session.key, /tmp/payload.enc, /tmp/session.key.enc

• /tmp/.pg_state, /tmp/pglog

Kubernetes:

• Pods: node-setup-{node_name} in kube-system

• Container name: setup, image: alpine:latest

RSA public key prefix (hardcoded in all three operations' payloads):

What to do right now

1. Check your litellm version: pip show litellm | grep Version

2. Pin to <=1.82.6 in all environments

3. Run snyk test --package-manager=pip

4. If you had 1.82.7 or 1.82.8 installed: rotate credentials and check for persistence artifacts

5. Audit CI/CD pipelines for unpinned tool versions, including GitHub Actions

6. Check Kubernetes: kubectl get pods -A | grep node-setup-