CVE-2026-33634: The LiteLLM Supply Chain Attack That Compromised 2,500+ Organisations and 434,000 CI/CD Pipelines

In March 2026, a threat actor called TeamPCP pulled off what researchers at CloudSEK are now calling the largest AI infrastructure supply chain breach of the year — and most organisations only learned they were caught in the blast radius in August. The attack was quiet, surgical, and devastatingly effective: by poisoning a single open-source security scanner, the group gained a foothold across the CI/CD pipelines of more than 2,500 organisations, potentially exposing the secrets of every company that builds or deploys AI with LiteLLM, one of the most popular Python libraries for routing requests across LLM providers.

If you run AI workloads, operate a DevSecOps pipeline, or touch any infrastructure that routes traffic to OpenAI, Anthropic, Azure AI, or similar platforms, this story is about you.

How a Security Scanner Became the Attack’s Keystone

The TeamPCP campaign did not begin with LiteLLM. It began on 19 March 2026 with Trivy — Aqua Security’s ubiquitous open-source vulnerability scanner used by tens of thousands of DevOps teams to check containers and repositories for known CVEs. Aqua announced on 20 March that a misconfigured GitHub Actions workflow inside the Trivy project had allowed TeamPCP to exfiltrate CI/CD secrets and signing credentials, enabling them to force-push a malicious binary in Trivy v0.69.4.

The malicious Trivy build was itself an infostealer: when executed inside a CI runner, it harvested environment variables, cloud tokens, and SSH keys and exfiltrated them silently. Because LiteLLM’s own CI/CD pipeline automatically installed Trivy as a scanning dependency, the compromised scanner gained legitimate, trusted read access to LiteLLM’s runner environment — including the project’s PyPI publishing tokens.

Within four days, the cascade had spread further. By 23 March, TeamPCP had used stolen credentials to compromise Checkmarx’s ast-github-action and kics-github-action repositories, modifying these infrastructure-as-code scanning workflows to harvest pipeline data from any CI job that ran them. On 24 March, the attackers used LiteLLM’s stolen PyPI credentials to push the weaponised packages.

Inside the Weaponised Packages: A Three-Stage Attack Chain

The two malicious LiteLLM releases contained different but complementary mechanisms, a deliberate engineering choice that maximised coverage:

Version	Delivery Mechanism	Trigger Condition
1.82.7	Base64-encoded payload injected into litellm/proxy/proxy_server.py	Fires when the proxy module is imported
1.82.8	litellm_init.pth file added to the package	Fires on every Python interpreter startup — no import needed

Once triggered, the malicious code executed a three-stage sequence:

1. Stage 1 — Credential Harvest: The payload collected environment variables, SSH keys, cloud credentials (AWS, Azure, GCP), Kubernetes kubeconfig data, shell history, database connection strings, CI/CD tokens, and AI provider API keys. All harvested data was encrypted with AES-256 session keys wrapped in RSA-4096 before transmission.
2. Stage 2 — Exfiltration and Lateral Movement: Encrypted data was sent to the attacker-controlled domain models.litellm[.]cloud. The payload then attempted lateral movement inside Kubernetes environments, deploying privileged pods named node-setup-* with containers labelled kamikaze or provisioner to maintain cluster-level persistence.
3. Stage 3 — Persistence: A systemd unit and a polling script at ~/.config/sysmon/sysmon.py were installed to survive reboots, checking checkmarx[.]zone/raw for follow-on command-and-control payloads — giving TeamPCP the ability to deploy additional tooling at any future time.

A parallel compromise of Telnyx (PyPI versions 4.87.1 and 4.87.2) delivered a second-stage payload hidden inside a WAV audio file using XOR-based steganography — a technique that bypasses most static analysis tools and highlights TeamPCP’s above-average operational sophistication.

The Blast Radius: Who Was Caught in the Net

LiteLLM is not a niche library. With approximately 97 million monthly PyPI downloads, it sits at a chokepoint in the global AI infrastructure stack. Organisations that use it include government contractors, financial institutions, healthcare providers, and some of the world’s largest technology companies.

CloudSEK’s August 2026 research reconstructed the dependency graph and mapped the exposure to 2,488 organisations with high-confidence matches tied to corporate domains, repositories, credentials, or infrastructure. The named list reads like a who’s-who of global enterprise: NVIDIA, Samsung Electronics, Cisco Systems, Siemens, S&P Global, ServiceNow, Deloitte, Vodafone, X Corp, Zscaler, FedEx, Volkswagen, Thales, the London Stock Exchange Group, AWS, Salesforce, Accenture Federal Services, Regeneron Pharmaceuticals, HP, Deutsche Bahn, and Orange, among many others.

For Indian enterprises, the exposure is a sharp reminder that open-source AI tooling creates invisible upstream dependencies. Any organisation running AI inference, LLM proxy infrastructure, or AI-powered security tooling may have been silently affected — even if LiteLLM was pulled in transitively through a third-party vendor or managed service.

The FBI FLASH Warning: This Isn’t Over

Critically, the danger did not end when the malicious packages were pulled from PyPI. In July 2026, the FBI issued FLASH advisory FLASH-20260702-01, warning that actors affiliated with TeamPCP are likely to weaponise the harvested credentials long after the original intrusion — meaning further supply chain attacks, credential-stuffing campaigns, and AI API abuse remain a live threat for any organisation that was exposed in March.

The 40-minute window during which the packages were live was not an accident — automated pipelines do not wait for human approval before pulling the latest package version, and they do not check PyPI hashes unless explicitly configured to do so. Dependency pinning and hash verification are precisely the controls that most teams skip in practice, and TeamPCP knew it.

What You Should Do Right Now

The attack is novel in scale but tractable in response. Here is what Sanjay Seth recommends as immediate and short-term actions for any organisation operating AI workloads or modern CI/CD pipelines:

Immediate (24–72 hours)

• Audit your dependency tree. Run pip show litellm across all environments. If you see versions 1.82.7 or 1.82.8, treat those systems as fully compromised. Also check for Telnyx 4.87.1 and 4.87.2.
• Hunt for IoCs. Check for the filesystem persistence markers: litellm_init.pth, ~/.config/sysmon/sysmon.py, /tmp/pglog. In Kubernetes, inspect all pods for names matching node-setup-* or containers named kamikaze or provisioner. Block outbound connections to models.litellm[.]cloud, checkmarx[.]zone, and 83.142.209[.]203.
• Rotate every secret. Assume any credential reachable from a LiteLLM or Trivy runner — cloud IAM keys, AI provider API keys, database passwords, CI tokens, SSH keys, PyPI tokens — is compromised. Rotate immediately. Invalidate and reissue all affected sessions and service accounts.
• Rebuild from known-good images. Do not simply uninstall the malicious package. The .pth file technique in 1.82.8 persists across reinstalls. Rebuild CI/CD runners and affected containers from verified base images with pinned, hash-verified dependencies.

Short-Term (1–4 weeks)

• Pin dependencies and verify hashes. Use pip install --require-hashes and commit a requirements.txt or pip.lock with SHA-256 hashes for every package your pipelines consume.
• Enforce least-privilege in CI/CD. CI runners should never have production cloud credentials or publishing tokens in their environment. Use short-lived, scoped tokens and OIDC federation where available.
• Adopt a Software Bill of Materials (SBOM). Generate SBOMs for every build artefact. This is the only scalable way to detect future supply chain compromises before they propagate into production.
• Review GitHub Actions workflow permissions. Any workflow that installs third-party actions or scanners should run with minimal permissions and pin action versions to commit SHAs, not floating tags.

Frequently Asked Questions

How do I know if my organisation was affected by the LiteLLM supply chain attack?

Check whether any of your environments — including CI/CD runners, developer machines, or containerised applications — installed LiteLLM versions 1.82.7 or 1.82.8 between 24 and 27 March 2026. Even if the installation window was brief, the .pth persistence mechanism means the malware may still be present. CloudSEK has published an exposure check tool at their website to help organisations verify their exposure.

Is upgrading to the latest LiteLLM version enough to remediate the infection?

No. The litellm_init.pth file installed by version 1.82.8 executes on every Python interpreter startup and survives a simple package upgrade or reinstall. You must rebuild affected environments from clean base images and verify all credentials were rotated, since harvested secrets remain valid and exploitable regardless of whether the malware is still present.

Why was TeamPCP’s access to Trivy enough to compromise LiteLLM?

LiteLLM’s CI/CD pipeline automatically installed Trivy to perform vulnerability scanning during builds. Because the malicious Trivy binary ran inside the same trusted runner environment as LiteLLM’s build process, it had access to the environment variables that contained LiteLLM’s PyPI publishing token — a single secret that gave TeamPCP the ability to publish packages under LiteLLM’s official identity. This is a textbook example of why third-party tools running in privileged CI contexts must be pinned, hash-verified, and granted only the minimum permissions they need.

What does the FBI FLASH advisory mean for my organisation’s risk posture?

FLASH-20260702-01 signals that TeamPCP is still operational and likely sitting on a large cache of harvested credentials. Even if you patched in March, stolen credentials that were not rotated remain live attack surface. The advisory specifically warns of follow-on supply chain attacks and AI API abuse — attackers using stolen LLM API keys to run inference at the victim’s cost, or to exfiltrate sensitive prompts and completions sent through the proxy.

The Zero-Trust Lesson Hidden in Plain Sight

The LiteLLM breach is not primarily a story about a compromised package. It is a story about implicit trust in the software supply chain. TeamPCP did not need a zero-day. They did not need to break encryption or compromise a perimeter firewall. They needed a misconfigured GitHub Actions permission and one team that hadn’t pinned their scanner version.

The zero-trust principle — never trust, always verify — applies equally to the code your organisation pulls from the internet. Every open-source dependency is a third-party vendor. Every CI/CD action is a privileged process. Every token stored in a build environment is a credential that deserves rotation and scope-limiting.

As India’s AI adoption accelerates across BFSI, healthcare, government, and manufacturing, the attack surface for AI supply chain compromise is growing faster than most security teams’ ability to inventory it. The organisations that recover cleanly from events like this are the ones who treated their ML infrastructure with the same rigour as their production network — segmented, monitored, and zero-trust from the start.

If you are not sure whether your AI and DevOps infrastructure meets that bar, now is the right time to find out — before the next TeamPCP campaign lands.