AVX-SEC-2026-003: LiteLLM Security Advisory

Aviatrix is publishing this advisory to provide defensive guidance related to LiteLLM Supply chain compromise. Since this compromise surfaced on March 24, the Aviatrix® Threat Research Center has been tracking the attack in detail. This advisory summarizes what we know, what it means for your environment, and the specific steps to contain it.

Helpful Resources:

LiteLLM Supply Chain Compromise Explainer

LiteLLM Technical Threat Brief

Threat Research Center (TRC) Teampcp Supply Chain Attack 2026:

What Happened:

Threat actor TeamPCP compromised Aqua Security's Trivy vulnerability scanner (v0.69.4-v0.69.6), used it to steal LiteLLM's PyPI publishing credentials from their CircleCI pipeline, then published two backdoored releases on March 24, 2026.

Both versions harvest cloud credentials (AWS, GCP, Azure), AI API keys, SSH keys, Kubernetes secrets, and environment variables, then encrypt and exfiltrate the bundle to attacker infrastructure. Version 1.82.8 is the more dangerous of the two: it drops a .pth file into Python site-packages that runs the payload on every Python startup across the host, with no import required.

Exfiltration Endpoints/IOCs: 

IP Addresses

Domains

Take These Steps Now:

1. Block Data/Secrets Exfiltration using Aviatrix DCF (Distributed Cloud Firewall).

2. Remove litellm v1.82.7 and v1.82.8 from all environments. Downgrade to v1.82.6 or earlier.

3. Search all hosts for litellm_init.pth in Python site-packages directories and delete it.

4. Rotate all credentials, API keys, and tokens on any system where either version was installed.

5. Audit CI/CD pipelines for unpinned Trivy usage. Pin to v0.69.3 or later.

Containment: Block Malicious Hosts (Controller versions >= 7.2)

This stops credential exfiltration and beacon traffic at the network layer from any source in your environment. Execute this first regardless of whether your K8s cluster is onboarded to Aviatrix.

The following steps guide you through creating a SmartGroup for the TeamPCP campaign's known attacker infrastructure within Aviatrix CoPilot.

1. Create SmartGroup: TeamPCP-C2-Infrastructure

This SmartGroup consolidates all identified attacker-controlled endpoints associated with the various stages of the TeamPCP campaign.

Steps: Go to CoPilot → Security → SmartGroups → + Create SmartGroup

2. Creating Distributed Cloud Firewall (DCF) Rules 

Navigate to: CoPilot → Security → Distributed Cloud Firewall → Policies → + Create Rule 

DCF Rule 1: Block TeamPCP Command and Control (C2) Exfiltration

This rule is designed to stop the Stage 1 credential POST to TeamPCP Exfiltration Endpoints  before it leaves your environment. It is applied universally, as the Source is set to Anywhere, covering all workloads, VMs, CI/CD runners, and pods across every Spoke Gateway.

DCF Rule 2: Automated ThreatGroup Blocking

Aviatrix provides automated protection against newly registered malicious infrastructure through its continuously-updated threat intelligence feed, removing the necessity for manual rule updates. This feed already includes three of the four known Indicators of Compromise (IOC) IPs, demonstrating that configuring this feature would have provided automatic basic protection.

3. Rule Priority Order

The priority for DCF rules is as follows:

1. Priority 1 [DENY]: BLOCK-TeamPCP-C2-Exfiltration

2. Priority 2 [DENY]: BLOCK-ThreatGroup-C2

These two rules effectively block all currently identified exfiltration and beaconing paths across any environment. 

Beyond the Immediate Fix: What's Next

The TeamPCP supply chain campaign is not a one-time event. Since the initial Trivy compromise in late February 2026, TeamPCP has demonstrated a consistent and accelerating pattern: every package they compromise yields credentials that unlock the next target. Trivy led to LiteLLM. LiteLLM led to Telnyx — three days later. Each wave brings refined techniques, new C2 infrastructure, and persistence artifacts specifically renamed to bypass detection rules written after the previous attack.

If your organization runs AI workloads or Kubernetes clusters, you are in the target profile for this campaign and future ones like it. Blocking known-bad IPs and domains is necessary but not sufficient, threat actors rotate infrastructure faster than threat feeds update. The only durable defense is a network posture that limits what your AI workloads can reach, regardless of what C2 domain the attacker registers next.

The most effective defense is egress control. Organizations that enforce default-deny network-layer policies, allowing traffic only to whitelisted, permitted domains, would have automatically prevented this data exfiltration, regardless of the host processes. Deploying controls over what your AI workloads can access on the network is the highest-leverage defense strategy available today.

Recommendation

Implement Containment rules immediately on your current Controller version, this stops the known threat today. Then treat the upgrade to Controller 8.2 as a priority security action: it is the version that enables the proactive, zero-trust egress posture that protects you from the next attack in this campaign, and the one after that. Hence as next steps proceed to contact Aviatrix Support to upgrade to Controller 8.2

If you are not yet running egress controls on your AI workloads, we can help you get there. Leverage our Breach Lock Under Attack program and an Aviatrix technical resource will reach out to coordinate with your account team, activate DCF, and perform a  DCF policy review specific to your environment.

Aviatrix Threat Research Center

AVX-SEC-2026-003 | March 2026