Skip to content
Code & Context logoCode&Context
SecuritySecurityAISupply ChainPythonDevOps

Why AI Infrastructure is the New Target: Lessons from the LiteLLM PyPI Breach

The rapid adoption of AI has created a lucrative attack surface. On March 24, 2026, threat group TeamPCP compromised the LiteLLM Python package, exfiltrating developer secrets and cloud credentials from thousands of environments.

Saurabh Prakash

Author

Mar 25, 20269 min read
Share:

The rapid adoption of Artificial Intelligence has created a new, highly lucrative attack surface for cybercriminals: the AI software supply chain[3]. On March 24, 2026, this vulnerability was exposed when the threat group known as TeamPCP compromised the widely used Python package LiteLLM[1]. The attack successfully exfiltrated highly sensitive developer secrets and cloud infrastructure credentials, serving as a stark warning to the AI development community about the hidden dangers of open-source dependencies[3].

The Target: Why LiteLLM?

LiteLLM is an open-source Python library and proxy server that provides a unified interface to call over 100 Large Language Model (LLM) APIs — including OpenAI, Anthropic, AWS Bedrock, and Google VertexAI — using a standard format[2].

Because it acts as a proxy, LiteLLM sits directly between enterprise applications and AI service providers, meaning it handles some of the most sensitive API keys, environment variables, and corporate data flows[3].

With over 97 million monthly downloads (~3.4 million daily) and a presence in approximately 36% of all cloud environments[4], compromising this single package offered attackers an unprecedented blast radius[8].

Why LiteLLM is a high-value target

LiteLLM is the universal adapter sitting between your apps and every LLM provider. Compromising it means instant access to every API key, every environment variable, and every data flow passing through it[5].

The Anatomy of the Attack

The breach did not stem from a vulnerability in LiteLLM's source code, but rather through a sophisticated supply chain attack targeting its CI/CD pipeline[5].

The Kill Chain

  1. Trivy Compromise: The maintainers of LiteLLM were using Trivy, an open-source vulnerability scanner by Aqua Security. TeamPCP had previously compromised a Trivy GitHub Action script, injecting malicious code into existing version tags[5][6].

  2. Token Theft: When LiteLLM's pipeline ran the compromised scanner, it exposed LiteLLM's PYPI_PUBLISH token, which was stored as an .env variable[6].

  3. Malicious Publishing: Armed with this token and access to the compromised GitHub account of LiteLLM's CEO[9], the attackers bypassed normal security reviews and pushed two malicious versions to PyPI: 1.82.7 and 1.82.8[4][2].

  4. Diversion Tactics: To further obscure the attack, the threat actors automated a defacement of the LiteLLM GitHub repository and flooded the vulnerability reports with AI-generated spam comments[6].

The chain of trust is only as strong as its weakest link

LiteLLM's own code was never vulnerable. The attackers compromised a third-party security scanner used in CI/CD — a dependency of a dependency. This is the nature of modern supply chain attacks[6].

The Payload & Impact

The malicious package executed a multi-stage payload designed for maximum stealth and data extraction[3].

Stage 1: Execution and Evasion

Version 1.82.8 exploited Python's .pth file mechanism by dropping a file named litellm_init.pth[4][8]. Because Python automatically executes .pth files every time the interpreter starts, the malware ran silently in the background of any Python process — even if LiteLLM was never explicitly imported[1]. The payload was heavily obfuscated using double base64 encoding[7].

What are .pth files?

Python .pth files are normally used to add directories to sys.path. But they can also contain executable import statements that run every time a Python interpreter starts — making them a powerful and stealthy persistence mechanism.

Stage 2: Extensive Credential Harvesting

The malware swept infected machines for a massive array of sensitive data[2][4]:

CategoryTargeted Data
Cloud & InfrastructureAWS, GCP, and Azure credentials, Docker configs, Kubernetes files (admin.conf, kubelet.conf)[7]
Developer SecretsSSH private keys (id_rsa, id_ed25519), Git credentials, CI/CD secrets, .env files[7]
Financial & CommunicationCrypto wallet configs (Bitcoin, Ethereum, Solana), Slack and Discord credentials[7]

Stage 3: Exfiltration

To evade network monitoring, the malware encrypted the harvested data using an AES-256 session key, which was subsequently encrypted with a hardcoded 4096-bit RSA public key[3]. The encrypted archive (tpcp.tar.gz) was then exfiltrated to the attacker-controlled lookalike domain: models.litellm.cloud[2][8].

Persistence Mechanisms

The malware installed a persistent systemd user service via a script named sysmon.py that periodically polled a remote endpoint (checkmarx.zone) for new payloads[3][8].

Interestingly, attempts to analyze the C2 endpoint simply returned a link to the song "Bad Apple!!" — an evasion technique designed to frustrate security sandboxes[3].

In Kubernetes environments, the malware also attempted to create privileged backdoor pods (often named node-setup) on every node[2].

The Accidental Discovery: Defeated by a Bug

Despite the sophistication of the attack, it was discovered within a few hours due to a coding error by the malware authors[1].

A researcher named "calcium mcmahan" at FutureSearch.ai was using an MCP (Model Context Protocol) plugin inside the Cursor IDE[5]. This plugin pulled LiteLLM as a transitive dependency[2]. Because .pth files trigger on every Python startup, the malware spawned a child Python process to run its payload. However, that child process also triggered the .pth file, spawning another child, creating an exponential fork bomb that crashed the user's machine by consuming all available RAM[1][2].

If the attackers hadn't made this mistake...

AI researcher Andrej Karpathy noted that this was the "scariest imaginable" scenario — if the attacker had properly throttled the process, the malware could have remained undetected for weeks, silently draining credentials from thousands of environments[1].

The Transitive Dependency Problem

Because LiteLLM is a transitive dependency, users of popular frameworks like DSPY, Crew AI, and LM Studio were exposed without ever explicitly running pip install litellm[1][2].

Mitigation and Remediation Steps

If your team utilizes Python for AI development, you must assume your environment was targeted.

Immediate Actions Required

Step 1: Identify Exposure

Run pip show litellm across all virtual environments, CI/CD pipelines, and containers. If versions 1.82.7 or 1.82.8 are found, the system is compromised[2]. The safe version to pin to is 1.82.6[1].

Step 2: Complete Secret Rotation

Treat every secret on the affected machine as compromised. Fully revoke and regenerate all SSH keys, AWS/GCP access keys, Kubernetes tokens, and database passwords[3][2].

Step 3: Purge Persistence Artifacts

Search for tpcp.tar.gz, /tmp/pglog, /tmp/.pg_state, and the persistence script at ~/.config/sysmon/sysmon.py[3][8]. Audit the kube-system namespace in Kubernetes for unauthorized pods (especially ones named node-setup)[2].

Step 4: Adopt Dependency Hygiene

Pin all dependencies to exact versions to prevent automatic malicious updates. Use hash verification and isolate credential management from build environments[2][7].

Indicators of Compromise (IOCs)

IndicatorLocation / Description
litellm_init.pthSite-packages directory
tpcp.tar.gzEncrypted exfiltration archive
/tmp/pglogTemporary log file[3]
/tmp/.pg_stateState tracking file[3]
~/.config/sysmon/sysmon.pyPersistence script[3]
models.litellm.cloudExfiltration domain
checkmarx.zoneC2 polling endpoint
node-setup podsKubernetes backdoor pods in kube-system[8]

The Bigger Picture

This attack is not an isolated incident. It represents a structural vulnerability in how the AI ecosystem is built[3]. The same qualities that make open-source AI tools powerful — wide adoption, deep integration, broad access to credentials — make them irresistible targets[3].

Key Takeaways

  1. Your dependencies are your attack surface. Audit transitive dependencies, not just direct ones[1].
  2. CI/CD pipelines need zero-trust security. A compromised scanner is a compromised build[6].
  3. Pin, hash, and isolate. Every dependency should be pinned to an exact version with hash verification[7].
  4. LLM proxies are crown jewels. They hold the keys to every AI provider your organization uses[5].

References

[1]: "STARTUP HAKK" YouTube — AI Hacked! LiteLLM COMPROMISED!

[2]: "Fahd Mirza" YouTube — LiteLLM Supply Chain Attack Analysis

[3]: Sonatype Blog — Compromised litellm PyPI Package Delivers Multi-Stage Credential Stealer

[4]: Wiz Blog — LiteLLM TeamPCP Supply Chain Attack Overview

[5]: "Astarte Cybersecurity" YouTube — Aqua Security Trivy Compromise & LiteLLM Analysis

[6]: The Register — LiteLLM infected with credential-stealing code via Trivy

[7]: OX Security Blog — LiteLLM Supply Chain Attack: TeamPCP Context & Remediation

[8]: BleepingComputer — LiteLLM PyPI Package Compromised by TeamPCP

[9]: ReversingLabs — TeamPCP Supply Chain Attack Spreading to PyPI Ecosystem