LiteLLM on PyPI hit by TeamPCP: deep‑dive into the credential‑stealing malware campaign

Home » Python » LiteLLM on PyPI hit by TeamPCP: deep‑dive into the credential‑stealing malware campaign

For a few hours on March 24, 2026, a hugely popular Python package quietly turned into a powerful credential thief. Two poisoned releases of LiteLLM, a library widely used as a unified interface to large language models (LLMs), were uploaded to PyPI, briefly exposing a massive number of systems to a sophisticated supply‑chain attack.

The malicious versions, 1.82.7 and 1.82.8, bundled a multi‑stage payload able to siphon secrets from developer machines, CI/CD runners, cloud infrastructure and Kubernetes clusters, then exfiltrate them to attacker‑controlled servers. The campaign has been tied to the TeamPCP threat group, which has been on a months‑long spree hitting Trivy, Checkmarx tooling, Docker images, attacks on npm supply chain and now the PyPI ecosystem.

What is LiteLLM and why was it such a prime target?

LiteLLM is an open‑source Python library and proxy server that acts as a kind of universal adapter for LLM APIs. It lets applications talk to over a hundred different models – from providers such as OpenAI, Anthropic, Google, AWS Bedrock, Vertex AI and others – through a single, OpenAI‑style API.

Because of that role, the project has become deeply embedded across the AI ecosystem. Reports from multiple security vendors indicate that LiteLLM sees roughly 3-3.4 million downloads per day, with some telemetry suggesting it is present in about 36% of monitored cloud environments. For attackers, compromising a package with that footprint represents a rare chance to tap into a huge stream of sensitive data and credentials with one move.

By design, LiteLLM often sits directly between applications and multiple AI service providers. That position means it routinely handles API keys, environment variables, configuration files and other secrets required to reach external LLM endpoints. A backdoor in such a dependency can quietly intercept and exfiltrate those values without requiring a direct breach of the upstream platforms themselves.

The incident also underlines how entangled modern development is: local workstations, CI/CD pipelines, Kubernetes clusters and cloud accounts are all tied together via shared secrets and automation. A single compromised dependency in that graph can end up exposing credentials across many layers of an organization’s stack, amplifying the impact far beyond a single host.

How the malicious LiteLLM versions were introduced

The poisoned releases LiteLLM 1.82.7 and 1.82.8 were pushed to PyPI on the morning of March 24, 2026, around 08:30 UTC. They remained available for close to two hours before being quarantined by the PyPI security team and blocked by third‑party defenses, with removal reported around 11:25 UTC.

What makes this case notable is that the backdoor did not appear in the corresponding GitHub source. Endor Labs and other researchers found that the malicious logic was injected into the built wheel distributed on PyPI, not into the public repository, suggesting the compromise occurred during or after the build/publish process rather than via a visible code commit.

Specifically, analysts observed that the file litellm/proxy/proxy_server.py contained an embedded base64‑encoded payload that was absent from the same file in the GitHub commit. About a dozen lines were inserted between otherwise legitimate code blocks (for example, near the definition of REALTIME_REQUEST_SCOPE_TEMPLATE and the showwarning function). Those extra lines silently decoded and executed a hidden script whenever the module was imported.

In version 1.82.8, the attackers went a step further by dropping a .pth file named litellm_init.pth into the Python environment. Because Python processes all .pth files on interpreter startup, this ensured that the payload would run on every Python invocation, even if LiteLLM itself was never imported by the application.

This escalation made 1.82.8 significantly more dangerous: any Python script, test runner, build tool or automation launched in an environment with the compromised package installed would quietly trigger the credential‑stealing logic in the background.

Connection to the wider TeamPCP campaign

The LiteLLM compromise did not happen in isolation. Investigations by Sonatype, Wiz, Endor Labs and others link it to an ongoing supply‑chain campaign run by TeamPCP, a group that gained attention in late 2025 and has since targeted a string of open‑source projects and developer ecosystems.

Earlier in March, the same actors were tied to the backdooring of Aqua Security’s Trivy vulnerability scanner and related GitHub Actions, as well as to malicious variants of Checkmarx tools, including KICS, GitHub Actions and OpenVSX extensions. The campaign has also touched npm packages, Docker Hub images and Kubernetes environments, frequently reusing infrastructure, encryption schemes and persistence artifacts.

Tracing back the LiteLLM incident, maintainers disclosed that a PyPI publishing token stored as an environment variable in LiteLLM’s GitHub repository was exfiltrated via the compromised Trivy workflow. That token was then abused to publish the tainted PyPI releases, enabling the attackers to bypass two‑factor protections on user accounts and inject malicious wheels without altering public source code.

Researchers also point to suspicious commits and workflows created around March 23 in LiteLLM‑related repositories, including a short‑lived branch and a GitHub Actions workflow carrying a familiar RSA public key seen across other TeamPCP payloads. Telemetry from workflow runs suggests that secrets available to those CI runners may have been accessed and exfiltrated.

Across incidents, the group has shown a consistent pattern: steal credentials in one environment, then pivot to the next ecosystem. In this case, a misconfiguration in Trivy’s GitHub Actions allowed the theft of a privileged token; that token led to malicious Trivy releases and Docker images; those, in turn, enabled the compromise of Checkmarx tooling and ultimately the LiteLLM PyPI package.

How the LiteLLM malware operates

Analyses from multiple vendors describe the LiteLLM backdoor as a multi‑stage, base64‑obfuscated Python payload designed to be stealthy, flexible and resilient. The logic is organized in roughly three layers, each handling a different phase of the attack.

In the first layer, the injected code in proxy_server.py or the litellm_init.pth file decodes and launches a hidden orchestrator. Rather than using easily flagged functions like exec(), the script leans on subprocess calls and standard library functionality to run the decoded payload and capture its output, helping it blend into normal application behavior.

Once running, this orchestrator collects the output of the subsequent stage, encrypts the harvested data with AES‑256‑CBC and then encrypts the AES session key itself using a hard‑coded RSA public key baked into the code. The encrypted blob and key are bundled into an archive named tpcp.tar.gz, echoing other TeamPCP operations, and prepared for exfiltration.

The second layer is responsible for aggressive system reconnaissance and credential harvesting. It enumerates hostnames, user and network information, and environment variables, then scans a long list of paths and configuration files for sensitive material. Targets include:

• SSH keys and config files (client and server)
• Cloud credentials for AWS, GCP and Azure, including metadata‑derived tokens
• Kubernetes kubeconfig files, service account tokens and cluster secrets
• Environment files such as .env variants often used to store API keys
• CI/CD configuration, secrets and access tokens
• Terraform, Helm and other IaC or deployment artifacts
• Database connection strings and config files
• TLS/SSL private keys and authentication material
• Cryptocurrency wallets and related data

In some environments, the stealer doesn’t stop at collection. It attempts to actively use discovered credentials, for example by querying cloud provider APIs, pulling Kubernetes secrets or exploring reachable resources, increasing the chance of lateral movement and follow‑on compromise.

The third layer provides persistence and remote control. It writes a Python script to disk (commonly observed as sysmon.py) and registers it as a long‑running service, often disguised as something benign such as a “System Telemetry Service”. This service periodically contacts attacker infrastructure, typically every 50 minutes, to fetch additional commands or payloads.

Researchers note some quirky behavior here: when certain security vendors attempted to obtain the payload from the command‑and‑control endpoint, the server responded with a link to a remastered version of the song “Bad Apple!!”, apparently as a diversion tactic against automated analysis. On infected systems, though, the same mechanism can quietly deliver new functionality over time.

Exfiltration channels and attacker infrastructure

Across the LiteLLM incidents, analysts observed communication with at least two main attacker‑controlled domains: modelslitellmcloud and checkmarxzone. These align with infrastructure used in earlier TeamPCP activity and serve distinct roles.

The encrypted archive tpcp.tar.gz is typically uploaded to models.litellmcloud, allowing the operators to retrieve stolen credentials from thousands of downstream environments. In some variants, different subpaths of checkmarxzone (for example, checkmarxzone/raw or .../vsx) are used to deliver persistence scripts or additional stages.

On compromised systems, defenders have reported a set of recurring indicators of compromise (IoCs) associated with the LiteLLM malware:

• Presence of the archive tpcp.tar.gz in temporary or working directories
• Temporary files such as /tmp/pglog and /tmp/.pg_state
• Python script and configuration paths related to sysmon.py and a matching service file (often under user or systemd config directories)
• Unexpected litellm_init.pth files in Python site‑packages for version 1.82.8
• Outbound traffic or DNS lookups pointing to modelslitellmcloud or checkmarxzone

Malicious logic was traced to files including proxy_server.py (LiteLLM 1.82.7 and 1.82.8) and litellm_init.pth (1.82.8). Security vendors have cataloged hashes and further IoCs and are continuing to update their advisories as additional forensic details surface.

Impact on AI, cloud and CI/CD environments

Because LiteLLM is used heavily in AI‑driven applications and services, the practical blast radius of this compromise extends beyond simple package consumers. Cloud environments where LiteLLM served as the gateway to LLM providers are likely to have co‑located secrets in the same runtime or configuration space.

Wiz and other observers estimate that LiteLLM appears in around a third of observed cloud environments, underscoring the potential reach. Some sources cited by BleepingComputer have suggested that the number of data exfiltration events may reach into the hundreds of thousands, though independent confirmation of exact counts remains pending.

Notably, the malware emphasizes Kubernetes‑aware behavior. In many analyses, the payload attempts to deploy privileged pods across all nodes in a cluster, then use those pods to access secrets and configuration objects. In separate but related TeamPCP operations, researchers have seen Kubernetes clusters targeted with scripts that wipe nodes when the environment appears to be located in Iran, while installing backdoors (such as the so‑called CanisterWorm) elsewhere.

The focus on CI/CD tooling is similarly clear. By compromising Trivy GitHub Actions, Checkmarx VS Code extensions and GitHub Actions, and now LiteLLM, attackers gain entry points where automation already has broad privileges over repositories, build artifacts and deployment credentials. This approach turns otherwise security‑oriented tools into stepping stones for wider compromise.

FBI officials and industry researchers have warned that with large volumes of stolen credentials in hand, it is reasonable to expect more breach notifications, secondary intrusions and extortion attempts in the weeks and months following the initial LiteLLM disclosure.

Detection, containment and remediation steps

For organizations that may have pulled or executed LiteLLM versions 1.82.7 or 1.82.8 from PyPI, the guidance from security vendors and PyPI maintainers is blunt: treat affected systems as compromised. Simply uninstalling the package does not remove persistence mechanisms or undo any credential theft that may already have occurred.

Recommended immediate actions include:

• Identify any installations of LiteLLM 1.82.7 or 1.82.8 across developer machines, CI/CD runners, containers and production environments.
• Remove the malicious versions and pin LiteLLM to a known good release (with 1.82.6 widely cited as the last clean version at the time of reporting).
• Rotate all credentials accessible from affected environments: SSH keys, cloud provider keys and tokens, Kubernetes secrets, CI/CD secrets, database credentials, TLS keys and any wallets or payment‑related secrets.
• Search for persistence artifacts, such as sysmon.py, suspicious systemd service definitions, and unusual files under ~/.config or temporary directories like /tmp/pglog and /tmp/.pg_state.
• Inspect Kubernetes clusters for unexpected privileged pods, especially in namespaces like kube-system, and for unusual service accounts or role bindings.
• Monitor outbound connections and DNS queries for known attacker domains like models.litellmcloud and checkmarxzone.

In environments where the backdoor might have executed for any significant period, many experts suggest that a full rebuild from a trustworthy baseline may be the safest path, especially for critical infrastructure. Given the nature of the malware, subtle tampering or additional payloads cannot be ruled out purely by removing the LiteLLM package.

Organizations are also being encouraged to adopt more robust dependency management and supply‑chain defenses: pinning to specific, verified versions, enabling tools that block or flag known malicious packages at ingestion time, and incorporating automated behavioral analysis that can detect unexpected network or file system activity during builds and tests.

What the LiteLLM case says about AI software supply chains

The LiteLLM incident highlights a broader trend that has been building over the last few years: high‑leverage components in AI and cloud stacks are becoming prime targets for supply‑chain attackers. Rather than going after end‑user applications directly, threat actors are increasingly looking for points in the toolchain where compromising a single library or plugin yields access to many downstream organizations.

Packages such as LiteLLM effectively sit at a choke point for secrets. They mediate calls to AI providers, touch CI/CD and infrastructure automation systems, and often run with elevated permissions. As more enterprises rush to integrate LLM capabilities using open‑source tooling, the value of such components – and the incentive to backdoor them – only grows.

At the same time, the attack illustrates the challenges of defending build and publishing pipelines. In this case, attackers allegedly leveraged a Trivy workflow misconfiguration to steal a token, then used that token to push tainted packages to PyPI, all while leaving the public source tree apparently clean. Version tags and build steps became part of the attack surface, exploiting the fact that many pipelines rely on tags instead of pinned commits and may implicitly trust artifacts coming from familiar maintainers.

Vendors like Sonatype, Wiz and Endor Labs stress the importance of automated, real‑time safeguards that can spot anomalous behavior – such as previously unseen network destinations or encrypted exfiltration – even when package metadata and repository history look legitimate. Repository firewalls, threat‑intelligence‑driven scanners and contextual analysis of dependencies are increasingly seen as necessary layers, not optional extras.

For maintainers and organizations alike, the LiteLLM compromise is a reminder that secrets handling, CI/CD hardening and credential rotation are foundational to supply‑chain security. Incomplete or non‑atomic credential rotation in earlier incidents left openings that TeamPCP was able to reuse weeks later, demonstrating how a single misstep in incident response can cascade across ecosystems.

The campaign that swept up LiteLLM started with what looked like a limited workflow issue and has since spanned GitHub Actions, Docker Hub, the Shai-Hulud npm incident, OpenVSX and PyPI. With backdoors hiding in widely trusted tools and AI connectors, and stolen credentials flowing to attacker infrastructure, the episode underscores just how quickly the software supply chain can become an attractive, and highly effective, attack surface.