A developer at FutureSearch noticed his laptop grinding to a halt on March 24. Thousands of Python processes spawning uncontrollably. What looked like a runaway AI coding assistant turned out to be something far worse: a sophisticated supply chain attack that had compromised LiteLLM, one of the most critical packages in the AI ecosystem.

This isn’t a hypothetical threat model. This happened. And it should scare you.

LiteLLM: The Package You Didn’t Know You Depend On

LiteLLM is an open-source Python library that provides a unified API for dozens of LLM providers — OpenAI, Anthropic, Google, Mistral, and more. Instead of writing custom integration code for each, developers use LiteLLM as a universal translator.

It gets 95 million monthly downloads. It sits in environments packed with API keys, cloud credentials, and production configs. If you work in AI, there’s a good chance something in your stack depends on it — even if you’ve never installed it directly.

That’s exactly what makes it the perfect target.

How It Went Down

The attack wasn’t a smash-and-grab. It was a cascading chain orchestrated by a threat group called TeamPCP, and it started with a security tool — which is the kind of irony that would be funny if it weren’t terrifying.

The chain:

  • Late February: TeamPCP compromised Aqua Security’s Trivy GitHub Action — a popular open-source security scanner used in CI/CD pipelines. They rewrote Git tags to point to a malicious release carrying credential-harvesting payloads.
  • March 23: The same infrastructure hit Checkmarx KICS, another security tool. The attackers registered models.litellm.cloud — designed to look legitimate, controlled entirely by them.
  • March 24, 10:39 UTC: Using credentials stolen from LiteLLM’s CI/CD pipeline (which ran the compromised Trivy scanner), they published malicious version 1.82.7 to PyPI. Thirteen minutes later, version 1.82.8 followed.

A security scanner was the vector. The tool meant to keep the supply chain safe was the weak link that broke it.

Three Stages of Devastation

The malware operated with surgical precision:

Stage 1 — Credential Harvesting. SSH keys, AWS/GCP/Azure credentials, Kubernetes configs, .env files, database passwords, shell history, crypto wallet files, cloud metadata endpoints. Everything.

Stage 2 — Encrypted Exfiltration. Stolen data encrypted with a 4096-bit RSA key, bundled into a tar archive, and silently posted to the attacker-controlled domain.

Stage 3 — Lateral Movement. If a Kubernetes service account token was present, the malware read all cluster secrets across all namespaces, then deployed privileged pods on every node with persistent backdoors disguised as a “System Telemetry Service.”

Version 1.82.8 was especially nasty. It used a .pth file — a Python startup hook that fires on every Python interpreter startup. Your IDE starts Python? Infected. You run pip install? Infected. A CI/CD runner spins up? Infected.

Caught by Its Own Bug

Here’s the twist: the malware had a bug. Because .pth files fire on every Python process startup and the payload spawns a new subprocess, it created an accidental fork bomb. Each child process triggered the malware again, spawning more children exponentially. The machine crashed before the malware could finish its mission.

The developer who caught it — Callum McMahon at FutureSearch — used Claude Code to help investigate. What started as debugging a frozen laptop became full malware analysis and public disclosure, all within 72 minutes.

An attack targeting AI infrastructure, discovered through AI tools, analyzed by an AI assistant. The snake eating its own tail.

The Aftermath Was Messy

The GitHub issue (#24512) was flooded by hundreds of bot comments designed to bury legitimate analysis. The issue was closed as “not planned” using what appeared to be the compromised maintainer’s account. A clean tracking issue had to be opened separately.

Five hours after publication, the malicious versions were pulled from PyPI. But for a package downloaded 3.4 million times daily, five hours is an eternity. Roughly 47,000 installations of the compromised versions occurred during that window.

Why This Matters More Than a Typical Hack

This isn’t just another npm/PyPI incident to scroll past. The AI industry has some unique properties that make supply chain attacks especially devastating:

The dependency web is invisible. AI stacks are deeply nested. A tool like Cursor might pull in LiteLLM as a transitive dependency through an MCP plugin. You can’t secure what you can’t see.

AI environments are treasure troves. Unlike a compromised JavaScript widget on a marketing site, a compromised AI library sits next to API keys worth thousands per month, cloud credentials with broad permissions, and production Kubernetes clusters running inference workloads.

Python’s .pth mechanism is a time bomb. Any pip-installed package can include a .pth file that executes arbitrary code on every Python process startup. CPython maintainers have acknowledged the risk. No patch exists. In a world where Python is AI, this is unacceptable.

What You Should Do Right Now

If you’re building with AI tools:

  1. Pin your dependencies. No floating version ranges. Pin exact versions and update deliberately.
  2. Use lockfiles with hash verification. Tools like uv and pip-compile generate content hashes that catch tampering.
  3. Verify against source. Compare distributed packages against upstream GitHub source. No matching Git tag? Red flag.
  4. Adopt PyPI Trusted Publishers. Ties package publishing to specific GitHub Actions workflows, making stolen API tokens useless.
  5. Audit transitive dependencies. You may not use LiteLLM directly. Something you depend on might.
  6. Watch for anomalies. Unexpected network connections, mysterious files in ~/.config, sudden CPU spikes — these are warning signs.

The Uncomfortable Truth

The AI industry is spending hundreds of billions on frontier models and GPU clusters. The software supply chain connecting it all together? Held together with duct tape and good intentions.

The LiteLLM attack wasn’t a sophisticated zero-day. It was credential theft cascading through a chain of trust. The fix isn’t some magical new technology — it’s the boring, unglamorous work of supply chain hygiene: pinning versions, rotating credentials, auditing dependencies, and not giving your build pipeline the keys to the kingdom.

The next attack on AI infrastructure isn’t a question of if. It’s whether the industry learns from this one before it happens.