Backdoored LiteLLM on PyPI: Malware Triggers on Python Startup…

On March 24, 2026, two malicious LiteLLM versions exfiltrated credentials from over 50 categories via a .pth mechanism. The compromise was discovered only because of a bug in the payload.

On March 24, 2026, the Python package LiteLLM—an API proxy for language models with roughly 3.4 million daily downloads—distributed two malicious versions directly from the official PyPI repository. Versions 1.82.7 and 1.82.8 contained a credential stealer activated by the Python interpreter's .pth mechanism, which executes code without requiring an explicit import. The compromise originated in a security scanner, Trivy, used in the project's CI/CD pipeline: the tool designed to find vulnerabilities became the attack vector.

Key Takeaways

Versions 1.82.7 (10:39 UTC) and 1.82.8 (10:52 UTC) were published with valid PyPI credentials exfiltrated from a compromised Trivy GitHub Action (v0.69.4)
The payload used the file litellm_init.pth (34,628 bytes, double base64-encoded) to execute on Python interpreter startup, mapped to MITRE ATT&CK technique T1546.018

models.litellm.cloud

Discovery was triggered by an unintentional fork bomb in the payload, detected by Callum McMahon of FutureSearch
The RSA public key is identical to those in compromised Trivy and KICS payloads, confirmed by Wiz, serving as the primary attribution link to the TeamPCP campaign

How the Publishing Channel Became the Target

LiteLLM is an open-source API proxy that standardizes access to dozens of language model providers. It is not an end-user application; it is hidden infrastructure, often a transitive dependency of larger AI frameworks. According to the project's official statement, on March 24, 2026, versions 1.82.7 and 1.82.8 were published to PyPI from an account with valid credentials—not via typosquatting or a counterfeit package.

The root cause was the exfiltration of the PYPI_PUBLISH token from the CI/CD pipeline. The vector: a Trivy GitHub Action—a container vulnerability scanner—in a compromised version (v0.69.4). LiteLLM's configuration lacked version pinning for Trivy. The tool built to protect the supply chain concentrated the privileges necessary to violate it.

The two malicious versions show rapid operational iteration: 13 minutes between the first and second publication. Version 1.82.7 contained the payload in proxy_server.py; 1.82.8 added the stealthier .pth mechanism. The packages remained available on PyPI until 15:27 UTC: a window of roughly three hours per Snyk, or about 40 minutes per LiteLLM's official timeline, which indicates an earlier quarantine.

The .pth Mechanism and Payload Invisibility

The core technique of the second stage is the file litellm_init.pth, placed in site-packages. The Python interpreter processes .pth files at startup: they normally contain search paths, but can also execute arbitrary code if they contain import statements. This meant the payload activated with every Python startup, regardless of which module the user imported.

Snyk describes the file as double base64-encoded, 34,628 bytes, designed to evade superficial static analysis. Trend Micro confirms the mechanism requires "no import" by the victim. Once active, the payload operated in three phases: credential collection from over 50 categories (cloud, crypto wallets, environment variables, CI/CD configurations), encryption with AES-256-CBC using an RSA-4096 key, and exfiltration via HTTPS POST to the domain models.litellm.cloud.

Persistence was ensured by a systemd service named sysmon.service, a name mimicking legitimate monitoring tools. The malware also implemented lateral movement in Kubernetes environments. The C2 domain had been registered on March 23, 2026—one day before publication—and does not belong to BerriAI, the company behind LiteLLM.

The Fork Bomb That Exposed the Attack

Detection did not come from proactive package analysis but from an attacker error. The payload contained an unintentional process recursion—a fork bomb—that caused exhaustive resource consumption on infected systems. Callum McMahon of FutureSearch identified the anomaly and opened GitHub issue #24512.

The account of maintainer Krrish Dholakia, co-founder and CEO of BerriAI, was already compromised. ReversingLabs documents that the attacker used this access to close issue #24512 with a commit titled "teampcp update," attempting to suppress disclosure. ICT Security Magazine reports 88 bot comments from 73 accounts in 102 seconds, a coordinated spam operation to bury the report. The discussion reached 324 points on Hacker News, forcing public visibility.

"TeamPCP did not need to attack LiteLLM directly. They compromised Trivy, a vulnerability scanner running inside LiteLLM's CI pipeline without version pinning. That single unmanaged dependency handed over the PyPI publishing credentials, and from there the attacker backdoored a library that serves 95 million downloads per month." — Jacob Krell, senior director Suzu Labs, via ReversingLabs

Attribution and the Extended Campaign

The strongest attribution link is the identical RSA public key across the LiteLLM, Trivy, and KICS payloads. Wiz confirmed this match across all three operations. ReversingLabs describes the key as a "well known RSA public key seen across multiple payloads," indicating a coordinated campaign under the TeamPCP label.

TeamPCP publicly claimed responsibility via ICT Security Magazine, stating that "many of your favourite security tools and open-source projects will be targeted in the months to come." The statement explicitly identifies security tools as privileged targets: they concentrate access, credentials, and implicit trust in pipelines.

The brief does not specify whether the domain models.litellm.cloud has since been sinkholed or remains active. No infrastructure overlaps linking TeamPCP to other threat actor groups have emerged to date.

Why This Matters

The brief documents no specific remediation measures beyond certifying version 1.82.6 as safe and releasing CI/CD pipeline v2 with version 1.83.0. It does not state whether LiteLLM implemented version pinning for Trivy or other GitHub Actions after the incident. It is not declared whether Snyk or other vendors released dedicated detection rules for the .pth payload hash.

The official Docker image ghcr.io/berriai/litellm was unaffected, thanks to pre-existing version pinning in requirements.txt. This detail highlights a discontinuity: the practice was applied to the container but not to the CI/CD pipeline that generated the PyPI package.

The brief does not quantify the exact number of installations of the compromised versions during the exposure window. It does not specify the full extent of data actually exfiltrated from the C2 domain, nor the status of any legal investigations into the identities of TeamPCP members.

The Paradox of the Security Tool as Attack Vector

The incident inverts the logic of supply chain security. Tools that audit dependencies and containers are preferential targets: they run with elevated privileges, access publishing secrets, and enjoy implicit trust. Their compromise generates no alarms—they do exactly what they are expected to do.

The .pth mechanism bypasses a fundamental assumption of traditional controls: that malicious code requires an explicit import. Software Composition Analysis (SCA) tools track import calls; the LiteLLM payload needed none. The technique is long-known, but its application to a PyPI package of this visibility demonstrates its practical effectiveness against standard defenses.

The download volume—roughly 3.4 million per day per Trend Micro and Snyk, or 95 million per month per an alternative estimate from ICT Security Magazine and ReversingLabs—places LiteLLM in a category of systemic risk. It is not a declared dependency; it is often transitive, hidden under layers of AI framework abstraction. The cumulative estimate of 480 million total downloads, from ReversingLabs, indicates an extended exposure surface over time.

Trend Micro's quote captures the structural problem: "Your CI/CD security tooling has the same access as your deployment tooling. If it's compromised, everything downstream is exposed." Supply chain security cannot rely on implicit trust in the very tools it tasks with verification.

Frequently Asked Questions

Why did the fork bomb expose the attack?

The fork bomb was a bug, not a defensive countermeasure. The attacker made a programming error in the .pth payload's recursive logic, causing uncontrolled process proliferation. This made visible malware otherwise designed to operate silently.

Why is the .pth mechanism particularly insidious?

Because it activates at Python interpreter startup, before any user import. Security controls based on declared dependency analysis or behavioral monitoring of the main application do not intercept it. It requires explicit inspection of .pth files in site-packages.

What is the difference between the 40-minute and 3-hour windows?

LiteLLM's official statement indicates a rapid package quarantine, roughly 40 minutes after initial publication. Snyk reports a longer window until final removal from PyPI at 15:27 UTC. The discrepancy likely reflects different metrics: time to internal quarantine versus time to public removal.

Information is based on the cited advisory and current as of publication.

Sources

Information is based on the cited source and current as of publication.

Sources

Sources and references