The LiteLLM supply chain attack

On March 24, 2026, a threat group known as TeamPCP published two malicious versions of LiteLLM — the widely used open-source AI/LLM gateway — to the PyPI registry. The packages litellm 1.82.7 and litellm 1.82.8 contained a credential stealer and were live for roughly 40 minutes before PyPI quarantined them. Because LiteLLM sees millions of downloads a day, the blast radius spanned thousands of organizations and hundreds of thousands of CI/CD pipelines — and the secrets it stole are the kind that end up for sale on the dark web.

A 40-minute window with an outsized blast radius

LiteLLM is an extremely popular way to put a single, OpenAI-compatible API in front of dozens of model providers. That also makes it a magnet for secrets: it commonly holds keys for OpenAI, Anthropic, Azure OpenAI and others, plus cloud and database credentials. A compromise of the package itself is therefore a compromise of everything it can reach.

The two poisoned releases were only live briefly, but "briefly" is enough. Automated CI/CD, Docker builds, and dependency bots pull new versions within minutes, and the malware ran the moment the Python interpreter started. Here is the timeline:

Reported impact figures put the exposure at more than 2,500 companies and 434,000 CI/CD pipelines that could have pulled the bad versions.

A supply chain attack delivered through another supply chain attack

The most striking part is the delivery. TeamPCP didn't breach LiteLLM directly — they poisoned the release of the Trivy security scanner, the same group tied to earlier incidents against KICS, Telnyx, and Aqua Security's tooling. LiteLLM's build pipeline installed Trivy without pinning it to a verified version, so the poisoned scanner ran inside LiteLLM's own CI/CD, stole its PyPI publishing tokens, and used them to push 1.82.7 and 1.82.8. A security tool became the backdoor.

Once installed, the payload ran in three stages:

Stage 1 — Credential theft

Scanned environment variables and the filesystem for AI provider keys (OpenAI, Anthropic, Azure), cloud credentials (~/.aws/credentials, GCP, Azure), SSH keys, and Kubernetes configs at ~/.kube/config, then bundled them for exfiltration.

Stage 2 — Lateral movement

Used Kubernetes service-account tokens to probe the internal K8s API, enumerate pods, services, and secrets, and look for privilege-escalation paths — even spinning up privileged alpine:latest pods to mount the host filesystem.

Stage 3 — Persistence

Installed a systemd service masquerading as a "System Telemetry Service" that polls a command-and-control server for further payloads. Infected machines often showed runaway RAM usage and fork loops, because the stealer re-ran on every Python interpreter startup.

What was exposed

If an affected version ran anywhere in your environment, treat all of the following — if reachable — as compromised:

• AI provider API keys — OpenAI, Anthropic, Azure OpenAI, and others held by the gateway.
• Cloud credentials — AWS, GCP, and Azure IAM keys and profiles.
• SSH keys and environment variables present on the host or in the pipeline.
• Kubernetes service-account tokens and kubeconfig files.
• Database passwords and application tokens.
• Package-publishing credentials (PyPI, registry tokens) — enabling further supply chain abuse.

Are you affected?

Only two versions are malicious. Anything else is clean.

Check for 1.82.7 / 1.82.8 everywhere they can hide: lockfiles, requirements.txt, Docker layers, CI/CD caches, self-hosted runner images, and developer machines.

Indicators of compromise

How to respond

1. Roll back or upgrade. Pin litellm==1.82.6 or install 1.83.0+ in requirements.txt / pyproject.toml.
2. Hunt and purge. Search all environments, CI/CD caches, and Docker images for 1.82.7/1.82.8. Remove litellm_init.pth, delete the sysmon persistence units in ~/.config/systemd/user/ and /etc/systemd/system/, and remove any node-setup-* pods. Rebuild self-hosted runner images.
3. Rotate every reachable secret. OpenAI / Anthropic / Azure API keys, AWS / GCP / Azure IAM credentials, Kubernetes service-account tokens, SSH keys, database passwords, and any registry/publishing tokens. Assume compromise until rotated.
4. Block egress to models.litellm.cloud and checkmarx.zone, and hunt historical connections to them in your logs.
5. Pin your build tools. The root cause was an unpinned scanner in CI/CD. Pin and verify every tool your pipeline installs.

Rotating isn't enough — find out what already leaked

Rotation closes the door going forward, but stolen secrets don't disappear. API keys, cloud credentials, and tokens harvested in campaigns like this are traded on dark web forums, dropped in Telegram channels, and bundled into stealer and exfiltration logs. The only way to know whether your data is already out there is to look.

Whiteintel continuously indexes stealer logs, marketplaces, and hacker forums, and lets you search whether your domains, employee and customer emails, or exposed secrets appear in leaked data — so you can prioritize which credentials to rotate first and catch exposure the LiteLLM incident (or any other) may have caused.

Frequently asked questions

What was the LiteLLM supply chain attack?

On March 24, 2026, the TeamPCP group published two malicious versions of LiteLLM — a widely used open-source AI/LLM gateway — to PyPI. litellm 1.82.7 and 1.82.8 contained a credential stealer and were live ~40 minutes before PyPI quarantined them. Anyone who installed or built with them may have had secrets harvested.

Which LiteLLM versions were compromised?

Only 1.82.7 and 1.82.8. The last safe version before the incident is 1.82.6; a clean 1.83.0 shipped on March 30, 2026. Pin to 1.82.6 or upgrade to 1.83.0+.

What data did the attack steal?

Environment variables plus AI provider API keys (OpenAI, Anthropic, Azure), cloud credentials (AWS/GCP/Azure), SSH keys, Kubernetes tokens and configs, database passwords, and package-publishing credentials. It also attempted Kubernetes lateral movement and installed a persistent systemd backdoor.

How was LiteLLM compromised?

Through another supply chain attack: TeamPCP poisoned the Trivy scanner, which LiteLLM's pipeline installed without version-pinning. The poisoned scanner stole LiteLLM's PyPI publishing tokens and used them to push the malicious versions.

What are the main indicators of compromise?

litellm_init.pth in site-packages; base64 injection in litellm/proxy/proxy_server.py; ~/.config/sysmon/sysmon.py and sysmon.service ("System Telemetry Service"); outbound traffic to models.litellm.cloud and checkmarx.zone; tpcp.tar.gz; and node-setup-* pods in kube-system.

How do I check if my leaked keys are on the dark web?

Because the stolen secrets are resold and dumped in leaked data, you can search for your organization's exposure. Run a free Whiteintel scan to see whether credentials tied to your domains, emails, or secrets are already circulating in stealer logs, marketplaces, and forums.