On March 24, 2026, a threat actor known as TeamPCP published two malicious versions of LiteLLM to PyPI. If you run AI workloads in the cloud and you use LiteLLM as your model proxy, this is the post you need to read before you do anything else today.
LiteLLM is not an obscure project. It is one of the most widely deployed open-source libraries for routing AI traffic to OpenAI, Anthropic, Gemini, and other model providers. It runs on dev laptops, CI/CD pipelines, and production inference services. It is the glue layer that sits between your applications and your AI providers. That is exactly why it was the target.
TeamPCP did not find a bug in LiteLLM. They poisoned the supply chain upstream and used stolen publishing credentials to push malware directly to PyPI under the legitimate package name. Two versions. v1.82.7 and v1.82.8. Both malicious. Both designed to steal everything on the host and send it home encrypted.
TL;DR
TeamPCP compromised Aqua Security's Trivy vulnerability scanner to harvest CI/CD secrets from any pipeline running Trivy without a pinned version. LiteLLM's CircleCI pipeline was one of them.
Using stolen PyPI publishing credentials, they published litellm v1.82.7 and v1.82.8 with embedded credential-stealing payloads. v1.82.8 is particularly dangerous: it runs on every Python interpreter startup via a .pth file. No import required.
The payload collects SSH keys, cloud credentials (AWS, GCP, Azure), Kubernetes configs, AI API keys, database passwords, SSL private keys, and shell history. Everything gets encrypted and shipped to attacker infrastructure.
If you run litellm v1.82.7 or v1.82.8 anywhere, treat your entire environment as compromised. Rotate everything.
PyPI status: The entire litellm package is currently suspended. All versions are unavailable. There is no clean version to upgrade to right now. LiteLLM has engaged Mandiant and will not publish a new release until the supply chain is verified.
Docker users: If you run the LiteLLM proxy as a container, you are not impacted. The Docker image pins all dependencies in requirements.txt and was not affected.
How a Security Scanner Became the Attack Vector
This is a multi-stage supply chain attack that unfolded over nearly a month. The first stage is the part that should keep your security engineering team up at night.
It started in late February 2026, when attackers exploited a misconfiguration in Trivy's GitHub Actions environment. That gave them a privileged access token and a foothold into the repository's automation and release processes.
On March 1, the Trivy team discovered the intrusion and attempted to contain it with credential rotation. The rotation was not comprehensive enough. The attacker retained residual access via credentials that were still valid after the rotation.
That gap is the reason this attack succeeded at the scale it did.
On March 19, at approximately 17:43 UTC, the attacker re-entered. They force-pushed 76 of 77 version tags in the aquasecurity/trivy-action GitHub repository, redirecting those trusted tags to malicious commits. They did the same across all tags in aquasecurity/setup-trivy. Simultaneously, a compromised Aqua service account triggered release automation to publish a malicious Trivy binary: v0.69.4.
The malicious Trivy binary did one thing the legitimate one does not: it collected environment variables and secrets and exfiltrated them via a Cloudflare Tunnel to attacker infrastructure. The payload executed before legitimate Trivy scanning logic, so compromised workflows appeared to complete normally. No alerts. Clean scan results. Credentials walking out the door.
Aqua identified and began containing the attack at approximately 20:38 UTC the same day. But the window was enough. Every CI/CD pipeline that ran Trivy v0.69.4 or referenced a trivy-action version tag between March 19 and March 20 should be treated as potentially compromised.
LiteLLM's pipeline ran Trivy via apt without a pinned version. When a CircleCI run hit during the compromise window, it pulled v0.69.4 — the malicious binary — and the PYPI_PUBLISH_PASSWORD and a GitHub Personal Access Token left the environment. TeamPCP now had the keys to publish under the litellm package name on PyPI.
They registered litellm.cloud as a typosquatting domain (the legitimate project is at litellm.ai), stood up models.litellm.cloud as their exfiltration endpoint on a VPS at 45.148.10.212, and on March 24, published their packages.
What the Malicious Packages Actually Do
Version 1.82.7 embeds the credential stealer directly in proxy_server.py. It executes when the proxy module is imported. That is bad, but it has a limiting condition: something has to import the library.
Version 1.82.8 removes that limiting condition entirely.
It drops a file called litellm_init.pth into Python's site-packages directory. Python automatically processes .pth files on interpreter startup. The malicious payload executes on every Python startup, for every Python process, on every host where v1.82.8 is installed. Your application. Your cron jobs. Your automation scripts. Anything running on that host using Python.
The payload is comprehensive. It collects:
SSH private keys
Environment variables (all of them)
AWS, GCP, and Azure credentials from config files, environment variables, and the cloud metadata service (169.254.169.254)
Kubernetes kubeconfig files and in-cluster service account tokens
AI provider API keys (OpenAI, Anthropic, and anything else sitting in your environment)
Database passwords
SSL private keys
Shell history
Everything gets encrypted with AES-256-CBC using a hardcoded RSA-4096 attacker public key, then POST'd to models.litellm.cloud. The encryption means the payload cannot be decrypted without TeamPCP's private key. If it left your environment, it is in their hands.
Why AI Infrastructure Is the Target
This is worth naming directly: targeting LiteLLM was not random. It was strategic.
LiteLLM deployments are co-located with exactly the credentials that are hardest to rotate and most valuable to abuse: AI provider API keys, cloud IAM credentials, and Kubernetes service account tokens. These live in the same environment because they have to. The proxy needs them to do its job. TeamPCP knew that.
Cloud IAM credentials enable account takeover and lateral movement across your cloud infrastructure. Kubernetes tokens enable movement across your container environments. AI API keys enable prompt injection campaigns, model abuse, data exfiltration through inference endpoints, and unauthorized API spend at scale. All of that is downstream from a single compromised Python package.
The AI toolchain is now part of the attack surface. If you have not been treating it that way, this attack is the reason to start.
The .pth Technique Is Not Going Away
The persistence mechanism in v1.82.8 deserves specific attention because it is not new and it is not going to stop being used.
Python .pth files have been a known persistence technique for years. They are simple to plant, they survive package upgrades in many configurations, and they execute code before your application logic runs. Host-level detection is possible, but it requires specifically looking for unexpected .pth files in site-packages directories. Most endpoint detection configurations are not tuned for this.
The implication is that if v1.82.8 was installed on a host, running pip uninstall litellm is not sufficient remediation. You have to explicitly find and remove litellm_init.pth from all Python site-packages directories on that host, then verify it is gone, before you can trust that host again.
Immediate Response Priorities
If litellm v1.82.7 or v1.82.8 is anywhere in your environment, here is the short list:
1. Remove the packages and the .pth file. Uninstall v1.82.7 and v1.82.8 from all hosts. Then search every Python site-packages directory for litellm_init.pth and remove it. Verify removal before moving on. Note: pip uninstall alone is not sufficient for v1.82.8.
2. Rotate all credentials. Assume everything on affected hosts was collected. AWS access keys, GCP service account credentials, Azure managed identity tokens, Kubernetes service account tokens, AI provider API keys, database passwords, SSH keys. All of it. The attacker has encrypted copies. Rotation is the only meaningful response.
3. Block egress to 45.148.10.212 and models.litellm.cloud. If you have network-layer egress controls, add explicit deny rules now. Check your flow logs for any past connections to that IP or domain. Those connections represent credentials that were successfully exfiltrated.
4. Pin your Trivy references to known-safe versions. The Trivy binary v0.69.4 is malicious. Safe versions are v0.69.2 and v0.69.3. For trivy-action, safe references are v0.35.0 (the only tag protected by GitHub's immutable releases feature during the attack). For setup-trivy, use v0.2.6. If your pipelines reference Trivy via a mutable version tag rather than a pinned commit SHA, change that now. This is not a LiteLLM-specific recommendation. It applies to every GitHub Action in your CI/CD stack.
5. Hunt for the tpcp-docs repository in your GitHub org. One of the attacker's fallback exfiltration mechanisms creates a repository named tpcp-docs in any GitHub org where credentials were successfully stolen. Search your org for it. Its presence is a confirmed indicator of successful exfiltration.
6. Audit your PyPI dependencies across every pipeline. Any package installed without hash verification and version pinning is a potential vector. The entire litellm PyPI package is currently suspended. Do not attempt to reinstall any version until LiteLLM confirms the supply chain is clean and publishes a verified release.
Indicators of Compromise
If you are hunting in your environment, here is the full list:
Type | Indicator |
IP | 45.148.10.212 (LiteLLM exfil server) |
Domain | models.litellm.cloud (LiteLLM exfil endpoint) |
Domain | scan.aquasecurtiy[.]org (Trivy C2, note deliberate typo) |
Cloudflare Tunnel | plug-tab-protective-relay.trycloudflare.com |
File | litellm_init.pth in any Python site-packages directory |
GitHub repo | tpcp-docs in your GitHub organization |
PyPI package | litellm v1.82.7 or v1.82.8 |
Trivy binary | v0.69.4 in container registries, artifact caches, or CI runners |
The Blast Radius Is Wider Than LiteLLM
One detail from Aqua's incident response that has not gotten enough attention: the stolen credentials from Trivy-compromised pipelines included NPM publish tokens. Those tokens are being actively weaponized to propagate malware across the NPM ecosystem.
If your CI/CD pipelines ran any of the compromised Trivy versions and you publish to NPM, treat your NPM publish tokens as compromised. This attack does not end at Python.
What This Tells You About AI Supply Chain Risk
The SolarWinds moment for AI infrastructure has been discussed as a hypothetical for a while. This is not SolarWinds scale, but the attack pattern is structurally identical: compromise a widely trusted tool in the supply chain, use that access to deliver malicious code to downstream consumers, harvest what you find there.
The detail that changes the calculus here is the incomplete rotation. When Aqua discovered the initial Trivy intrusion in late February, they rotated credentials. They thought they were clean. The attacker still had valid credentials and came back on March 19. The lesson is not "rotate credentials." The lesson is "incomplete rotation is worse than none, because it creates false confidence."
CISOs asking whether their AI toolchain is in scope for supply chain security should treat this as the answer.
Four Questions for Your Next Security Review
Are your Python dependencies pinned and hash-verified? Unpinned packages are a silent risk. This attack worked because LiteLLM's own pipeline ran Trivy unpinned. Apply the same audit to your own dependencies.
Do you have egress visibility from your AI workload environments? If a compromised host tried to POST credentials to an external IP, would you know? Network-layer flow logs with anomaly alerting on unusual outbound connections from AI workload VPCs are the detection layer that catches exfiltration in progress.
Can your workloads reach the cloud metadata service? The LiteLLM payload specifically targets 169.254.169.254 to harvest instance-attached IAM credentials. Blocking workload access to the metadata service at the network layer removes that attack path regardless of what is installed on the host.
How complete is your credential rotation process? Not "how long would it take." How thorough is it? The Trivy team rotated credentials on March 1 and missed enough residual access to let the attacker back in on March 19. A rotation playbook that does not account for service accounts, long-lived tokens, and automation credentials is not a rotation playbook. Run the drill. Audit the output.
The Bottom Line
TeamPCP demonstrated that the AI toolchain is a viable attack surface and that the credential density in AI workload environments makes it a high-value one. They did not need a zero-day. They needed one misconfigured GitHub Actions environment, a credential rotation that missed a few tokens, and one CI/CD pipeline running a tool without version pinning.
The technical mitigations are clear and documented. The harder shift is organizational: treating AI infrastructure with the same supply chain scrutiny applied to other critical dependencies, and treating credential rotation as a process that gets audited, not just executed.
The network layer is where this attack is stopped when everything else fails. Even a fully compromised host cannot exfiltrate credentials if the egress path does not exist.
To understand where your AI workloads have network exposure they should not have, start with the free Workload Attack Path Assessment.
Learn more about how you can block data exfiltration with Aviatrix Cloud Native Security Fabric (CNSF).
