Key Takeaways
On March 24, 2026, threat group TeamPCP pushed malicious versions of LiteLLM (1.82.7 and 1.82.8) to PyPI by first compromising Trivy, a trusted CI/CD security scanner — creating a cascading supply chain compromise.
The malicious payload silently harvested AWS credentials, SSH keys, Kubernetes service account tokens, database passwords, and environment variables from any Python environment that imported the package.
The attack went undetected because it arrived through signed, trusted code — not a phishing link or brute-force intrusion — exposing the fundamental weakness of perimeter-only security.
Beyond credential theft, the malware installed a persistent backdoor. Rotating credentials alone does not close the exposure window.
Workload-level egress enforcement — blocking any outbound connection not explicitly permitted — would have stopped data exfiltration at the network layer even after the malicious package was installed.
The LiteLLM supply chain attack was not a sophisticated hack of a hardened target. It was an exploitation of trust: trust in a security tool, trust in a public package registry, and trust in default cloud configurations that let workloads talk to anything on the internet. Understanding how that chain of trust collapsed is the first step toward building something more resilient.
What Is LiteLLM and Why Was It a Target Worth Attacking?
LiteLLM is a Python library that acts as a centralized gateway connecting AI applications to multiple large language model providers (OpenAI, Anthropic, Google, and others) through a single interface. It is the middleware layer that sits between internal systems and the model APIs developer teams use daily. Because it touches so many parts of the AI stack simultaneously, it holds a privileged position in cloud environments: it typically has access to API keys, cloud credentials, and configuration files for the services it routes between.
That access made it a high-value target. By March 2026, LiteLLM had accumulated roughly 3.4 million downloads per day1 and was present in an estimated 36% of cloud environments globally.2 A single compromised release had the potential to reach tens of thousands of organizations simultaneously. The threat actor group TeamPCP understood that math and built their operation around it.
How the LiteLLM Supply Chain Compromise Unfolded: A Multi-Stage Credential Stealer
The Trivy Compromise Opened the CI/CD Door
TeamPCP did not attack LiteLLM directly. Instead, they first compromised Trivy, an open-source container security scanner widely used in CI/CD pipelines to check software for vulnerabilities before release. Because LiteLLM’s build process relied on an unpinned version of Trivy, that dependency gave the attackers a foothold in the project’s release pipeline.
From that position, they extracted LiteLLM’s PyPI publishing credentials. With those credentials in hand, they uploaded two malicious packages, versions 1.82.7 and 1.82.8, to the official Python Package Index. Anyone running a routine pip install upgrade pulled in the compromised package without any warning. The affected versions passed standard integrity checks because they were signed with the legitimate project token.
The malicious payload activated the moment the Python interpreter started and loaded the LiteLLM module. A .pth file placed in the site-packages directory ensured the payload would run automatically at Python interpreter startup, meaning the payload executed even in environments where LiteLLM was a transitive dependency rather than a direct install. Teams that never intentionally installed LiteLLM were still exposed if another package in their dependency tree pulled it in.
What the Malicious Code Collected
Once active, the multi-stage credential stealer went to work immediately and quietly. The payload systematically harvested sensitive data from the host filesystem and running processes, including:
Cloud credentials: AWS access keys, AWS Secrets Manager tokens, Google Cloud service account tokens, and Azure credentials pulled from runtime configuration and configuration files
Kubernetes service account tokens and cluster secrets
SSH private keys from default key locations and SSH configuration files
Database credentials and database passwords from process memory and .env files
Shell history files that often contain plaintext credentials and commands run against cloud services
Git credentials and GitHub Actions runner environment tokens
Private keys from crypto wallets and other key stores
System telemetry and host metadata including hostname, IP configuration, and running processes
Session keys, RSA public key data, and password hashes
The collected data was packaged and transmitted to attacker-controlled infrastructure using standard HTTPS — traffic that looked identical to normal outbound API calls in most cloud environments. No anomaly detection fired. No alerts triggered. The malware also established a persistent systemd user service and installed a backdoor to maintain access even after the compromised package was removed.
Affected Versions and the Exposure Window
The malicious versions 1.82.7 and 1.82.8 were available on PyPI from approximately 10:39 UTC to 16:00 UTC on March 24, 2026.3 Any environment that ran a package update during that window is potentially compromised. LiteLLM released a clean version (v1.83.0) on March 30, 2026, built through a new CI/CD pipeline with stronger isolation controls.
If you upgraded LiteLLM during the exposure window, downgrading or removing the package is a necessary but insufficient response. The malware had time to execute, exfiltrate, and establish persistence before the compromise was discovered.
The Broader Supply Chain Campaign: TeamPCP’s Cascade
The LiteLLM compromise was not an isolated incident. It was one piece of a coordinated broader campaign by TeamPCP that ran across a 30-day window in early 2026, targeting interconnected parts of the modern developer ecosystem. In addition to LiteLLM, the group compromised Trivy, Checkmarx, and Telnyx within the same campaign window.
The strategy is deliberate: rather than attacking well-defended end targets directly, TeamPCP identifies trusted tools that sit upstream in the supply chain — security scanners, CI/CD integrations, and developer utilities — and uses those as delivery mechanisms for malicious packages. Because these tools are inherently trusted by the organizations using them, the embedded payload bypasses standard detection. The threat actor’s approach reflects a sophisticated understanding of how trust flows through open-source ecosystems: dependency to dependency, and poisoning one upstream node can contaminate everything downstream.
Mercor, a YC-backed AI company working with Anthropic and OpenAI, publicly confirmed it was affected by the incident.4 The exposure spread across finance, healthcare, logistics, retail, and government environments. Any sector running Python-based AI workloads was in scope.
Why Supply Chain Attacks Are So Hard to Catch
Supply chain attacks exploit a fundamental assumption that most security programs are built on: if software comes from a trusted source and passes integrity verification, it is safe to install. The LiteLLM attack broke that assumption entirely. The malicious packages were published with legitimate credentials. They passed PyPI’s standard checks. They were what they appeared to be: official LiteLLM releases, just with a malicious payload embedded.
This is the defining challenge of these attacks. Traditional perimeter security, antivirus scanning, and even most cloud security posture management tools are checking for known bad signatures. They cannot identify a weaponized package that arrives inside a clean trust chain. By the time behavioral anomalies might surface in logs, credentials are already gone.
Many organizations assume that if “LiteLLM” does not appear in their requirements file, they are safe. That assumption fails when LiteLLM is a transitive dependency — a package that another package they installed requires without any explicit choice on their part. Any Python project using popular AI frameworks or tooling stacks may have installed LiteLLM indirectly. Checking direct dependencies is not the same as auditing the full dependency tree.
GitHub Actions runner environments and other CI/CD pipelines typically operate with broad permissions by design — they need to deploy to cloud environments, push to registries, and access secrets. A malicious package installed during a CI/CD build run has the same access as the pipeline itself, which often includes cloud credentials with production-level permissions. The LiteLLM attack specifically targeted secrets injected into CI/CD context, where tokens for AWS, GitHub, and other services are commonly available at runtime.
The Security Gap This Attack Exposed: Permissive Outbound Defaults
The most important lesson from the LiteLLM supply chain attack is not about package hygiene. It is about what happened after the malicious code landed.
The malware executed, collected data, and transmitted it to an attacker-controlled server using standard outbound HTTPS. It succeeded because the cloud environments it ran in had no control over where their workloads were allowed to communicate. The default configuration of every major cloud platform — AWS, Azure, Google Cloud — permits workloads to reach any destination on the internet unless an organization has explicitly built controls to restrict that behavior. Most have not.
Two groups share responsibility for that gap.
The first is the developer ecosystem and the AI platform community. We have built tools, libraries, and frameworks that demand broad permissions and operate inside CI/CD pipelines that ship cloud credentials with production-level access. We have done that without enforcing the principle that what code can reach should be defined and enforceable, not assumed.
The second group is the major cloud providers — Amazon, Microsoft, Google, Oracle. Their underlying infrastructure is genuinely secure, and the physical and logical security of those platforms deserves real credit. The responsibility gap runs in a different direction entirely. Every major cloud platform ships with permissive outbound defaults. Unless an organization explicitly builds controls to restrict where its workloads can communicate, those workloads can reach anything on the internet.
That is a product decision. The analogy is direct: a car manufacturer that ships vehicles without standard brakes and offers them only as aftermarket add-ons bears real responsibility for what happens on the road. Making insecurity the default — while organizations assume they are protected — has contributed directly to the exposure that attacks like this one exploit.
This is not a gap that cloud security posture management tools close. Those tools scan for misconfigurations and alert on risk. They do not block traffic in real time. When the malware attempted to send collected data to its attacker-controlled infrastructure, there was nothing in place to stop the outbound connection.
The same logic applies to environment variables. Cloud credentials, database passwords, API keys, and Kubernetes service account tokens stored in process memory are exactly what this malware was designed to find and exfiltrate. If outbound connections to unknown destinations had been blocked at the workload level, those secrets would never have left the environment, regardless of whether the malware had already collected them.
What Actually Stops a Supply Chain Attack: Containment at the Network Layer
Every workload in a cloud environment should have a defined, enforced list of destinations it is permitted to communicate with. Traffic to any destination outside that list should be blocked automatically, by default, with no exceptions for “trusted” software. This is egress filtering, and it is the control that would have stopped the LiteLLM exfiltration even after an attacker’s payload landed in the environment.
If an AI workload is permitted to reach only its model provider endpoints, its database, and its internal services, then a piece of malware attempting to reach an attacker-controlled server has nowhere to go. The blast radius is contained. Credentials are stolen but go nowhere. The door is locked even after someone has obtained the keys.
This is the principle I described publicly during the incident:
“It was a known bad site. It’s like having the bad guys get into a vault, but you’ve got a set of bars that come across and keep them inside the vault. They’re there. That’s not great, but they can’t do the damage. They can’t take the jewels and the valuables back out.” 5
Traditional perimeter firewalls and legacy network security tools are not built for the traffic patterns of modern cloud environments. They operate at a level of abstraction that does not map to ephemeral containers, serverless functions, or dynamically scheduled Kubernetes pods. By the time a firewall rule is written and deployed, the workload it was meant to protect may no longer exist.
What is required is workload-level network security — controls that travel with the workload itself, that account for the dynamic nature of cloud infrastructure, and that enforce communication policies regardless of where a workload is running or how briefly it exists.
Why This Is Personal
Most people will read about this attack and file it under “enterprise IT problem.” That framing misses the actual stakes.
Consumers are downstream of every cloud security decision made by every organization they interact with. You did not vote on whether your healthcare provider implemented egress filtering. You have no visibility into whether the airline managing your travel has forensically cleaned its systems since the attack was discovered. You did not choose your bank’s outbound communication policies.
But when a hospital’s systems are disrupted, surgeries get postponed. When a financial platform buckles under sustained pressure, access to money disappears. When infrastructure that people depend on is compromised, the consequences do not stay inside enterprise balance sheets. They land on real people in real situations.
This is an argument for holding organizations accountable for the security decisions they make on behalf of the people who trust them. Boards and executive teams need to treat cloud network security as a business risk with real financial and operational consequences — not as a line item buried in an IT budget. The cost of not doing so has become impossible to ignore.
SSH Keys, Kubernetes Tokens, and the Persistent Backdoor Problem
Rotating credentials is the right first step after any breach of this kind. But it addresses only part of the problem, and specifically the easier part.
The LiteLLM malware did not just steal SSH keys and service account tokens. It also installed a persistent backdoor that sits in compromised environments waiting for a connection. An organization that has rotated all its cloud credentials since discovering the breach has closed one attack vector while leaving another open. The backdoor does not care about rotated credentials. It maintains a separate channel back to attacker-controlled infrastructure.
Fully remediating a compromise of this type requires treating every affected system — every container, every VM, every CI/CD runner that processed a build during the exposure window — as untrusted. That means rebuilding from scratch, not patching or cleaning. It means auditing cloud logs for access that used stolen credentials before they were rotated. It means searching for persistence mechanisms beyond the package itself: systemd user services, .pth files in the site-packages directory, scheduled tasks, and any RSA public key material added to authorized hosts.
The breadth of what this malware targeted is worth stating plainly:
AWS credentials and AWS Secrets Manager content
Google Cloud service account tokens
Kubernetes service account tokens and cluster secrets
SSH private keys used for server access
Database passwords stored in process environment and .env files
Git credentials for source code access
CI/CD secrets from GitHub Actions runner environments
Session keys, crypto wallets, and password hashes from the host filesystem
Any of those categories alone represents serious exposure. In combination, they represent potential access to entire cloud estates — not just a single service or environment. Organizations running LiteLLM in production environments with broad IAM permissions should assume the worst-case scope until forensics proves otherwise.
The LiteLLM Compromise in Context: Malicious Packages Are an Expanding Threat
This incident fits into a pattern that has accelerated significantly since 2023. Malicious packages targeting developers through PyPI, npm, and other public registries are now a standard tactic for threat actors looking to compromise cloud environments at scale.
What has changed is the sophistication of the delivery mechanism. Earlier campaigns relied on typosquatting — publishing packages with names similar to popular libraries hoping for a mistype during pip install. The LiteLLM attack bypassed that detection entirely by publishing through the legitimate project’s own account. Defending against that level of attack requires controls that operate after code lands in an environment, not just at the point of installation.
The Aviatrix Threat Research Center tracks active campaigns of this type and publishes indicators of compromise and behavioral analysis. The LiteLLM incident is documented alongside the broader TeamPCP campaign and related dependency-level compromises from the first quarter of 2026.
What Organizations Should Do Right Now
If there is any possibility that an environment ran versions 1.82.7 or 1.82.8 of LiteLLM, treat the environment as potentially compromised until proven otherwise:
Check pip install logs, CI/CD build logs, and Docker image build history for downloads of the affected versions.
Search Python environments for litellm_init.pth in the site-packages directory; its presence indicates the malware’s persistence mechanism was activated.
Review outbound traffic logs for connections to known attacker-controlled infrastructure, including models.litellm.cloud and checkmarx.zone.
Rotate all credentials accessible from affected environments: AWS access keys, Google Cloud service account tokens, SSH keys, database passwords, Kubernetes service account tokens, and any API keys stored as secrets in configuration or runtime context.
Rebuild affected environments from scratch. Do not attempt to clean or patch a potentially compromised system.
Beyond the immediate steps, these structural changes reduce blast radius going forward. Immediate remediation closes the current exposure; structural change reduces the risk from the next one:
Enforce workload-level egress filtering. Define approved outbound destinations for every workload and block everything else at the network layer. This is the control that would have contained the LiteLLM exfiltration.
Audit your full dependency tree, not just direct installs. Malicious packages arrive as transitive dependencies as often as they arrive as direct installs. Securing your software ecosystem requires visibility into the full dependency graph.
Pin dependency versions in CI/CD pipelines. LiteLLM’s exposure through Trivy was enabled in part by an unpinned dependency. Pinning versions and verifying checksums reduces the attack surface for upstream compromise.
Apply least-privilege access to AI workloads. The damage from this attack was amplified because many affected workloads had broad IAM permissions. Reducing the permissions available to any given workload limits what an attacker can do with stolen credentials.
Treat CI/CD environments as high-value targets. GitHub Actions runner environments and other CI/CD pipelines carry production credentials. They should be isolated, audited, and subject to the same egress controls as production workloads.
How Aviatrix Contained This Attack for Its Customers
Aviatrix’s Cloud Native Security Fabric enforces Zero Trust principles at the workload-to-workload and workload-to-internet layer, inline and in real time. When the LiteLLM malware attempted to transmit stolen cloud credentials, SSH keys, and environment variables to attacker-controlled servers, the Cloud Native Security Fabric blocked those outbound connections automatically. The credentials were collected but went nowhere. The blast radius was zero.
This is the architectural difference between detection and containment. Cloud security posture management tools and security posture scanners would have eventually flagged the compromised package after the fact — after exfiltration had already occurred. The Cloud Native Security Fabric blocked the exfiltration at the moment it happened, because the destination was not on the approved list of outbound destinations for those workloads.
The Cloud Native Security Fabric is agentless, requires no changes to application code, and enforces a single policy across AWS, Azure, Google Cloud, and Kubernetes environments simultaneously. When a new attack campaign emerges, policy updates propagate instantly across all covered workloads.
Organizations that want to understand their current exposure can start with a free Workload Attack Path Assessment at aviatrix.ai.
If you are actively responding to a potential compromise from this or another poisoned-package incident, Aviatrix’s Breach Lock program provides rapid response support for organizations under active attack.
Conclusion
This attack succeeded not because it was technically unstoppable, but because the environments it targeted were built on an assumption that has not held up: that trusted software from a trusted source is safe to run without further controls on what it can communicate with.
That assumption has always been fragile. Supply chain attacks make it untenable. The answer is not to scan more aggressively for malicious packages — although that matters — but to enforce controls that limit the damage when a compromised dependency inevitably lands. Egress filtering, workload-level Zero Trust, and least-privilege access do not prevent the attack. They prevent the attack from mattering.
The cost of not having those controls in place is now very visible. Contact Aviatrix to talk through what that looks like for your environment.
References
https://docs.litellm.ai/blog/security-update-march-2026
https://aviatrix.ai/resources/litellm-supply-chain-attack/
https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html
https://cycode.com/blog/lite-llm-supply-chain-attack/
https://www.herodevs.com/blog-posts/the-litellm-supply-chain-attack-what-happened-why-it-matters-and-what-to-do-next
https://www.okta.com/blog/threat-intelligence/litellm-supply-chain-attack--an-explainer-for-identity-pros/
Frequently Asked Questions
The LiteLLM supply chain attack was a March 2026 incident in which threat group TeamPCP pushed malicious versions of LiteLLM to PyPI by first compromising Trivy, a trusted security scanner used in LiteLLM's build pipeline. Any organization that installed the affected versions pulled malicious code directly into their environment.
Only versions 1.82.7 and 1.82.8 on PyPI were compromised. Version 1.82.6 and earlier are considered safe. LiteLLM released a clean version (v1.83.0) on March 30, 2026, built through a new hardened CI/CD pipeline.
The malware targeted cloud credentials, SSH keys, Kubernetes service account tokens, database passwords, environment variables, shell history, Git credentials, and GitHub Actions runner secrets from any Python process that imported the compromised package.
No. The malware also installed a persistent backdoor alongside stealing credentials. Affected environments should be fully rebuilt from scratch, and all systems with potential access during the exposure window should be treated as untrusted until forensic review is complete.
