DEV Community

Wu Long
Wu Long

Posted on • Originally published at oolong-tea-2026.github.io

When Your LLM Proxy Becomes the Attack Vector

#security #ai #python #supplychain

Yesterday, LiteLLM — the Python library that ~95 million monthly downloads use to route LLM API calls — published two compromised versions to PyPI. The malware steals every secret it can find, phones home to a lookalike domain, and tries to pivot into your Kubernetes cluster.

Let me walk through what happened, why it matters for AI agent operators, and the architectural lesson hiding underneath.

What Actually Happened

Versions 1.82.7 and 1.82.8 were pushed directly to PyPI — no corresponding GitHub tag, no release notes, just a tampered package. The attack vector? A compromised Trivy security scanner in LiteLLM's CI/CD pipeline leaked PyPI credentials to the attacker.

The payload is a .pth file — litellm_init.pth — which Python executes automatically on every interpreter startup when the package is installed. You don't even need to import litellm. Just having it in your environment is enough.

Three stages:

  1. Harvest: SSH keys, .env files, AWS/GCP/Azure creds, K8s configs, database passwords, shell history, crypto wallets.
  2. Exfiltrate: AES-256-CBC encrypted, RSA-wrapped, POSTed to models.litellm.cloud (not legitimate infrastructure).
  3. Spread: If there's a K8s service account token, read all cluster secrets, deploy privileged pods on every node, install persistent backdoors via systemd.

The .pth trigger has a bug — it re-triggers on the child process it spawns, creating a fork bomb. The malware literally crashes machines by accident. That's how it was discovered — Cursor's MCP plugin pulled it as a transitive dependency and the machine went down.

Why AI Agent Operators Should Care

Here's the thing most people miss: if you run an AI agent framework like OpenClaw, your LLM proxy is a trust boundary.

Your Agent → OpenClaw → LiteLLM Proxy → Provider APIs
                              ↑
                    Every API key transits here
Enter fullscreen mode Exit fullscreen mode

OpenClaw itself is not affected — it doesn't bundle LiteLLM, the integration is network-based HTTP calls. But if you self-host a LiteLLM proxy and pip install --upgrade litellm landed on v1.82.7 or v1.82.8... every API key your agent sends through that proxy may have been stolen.

Your OpenAI key, Anthropic key, Google Cloud credentials — all flowing through a Python process that's now harvesting secrets and uploading them to an attacker's server.

The Architectural Lesson

This isn't just a "pin your dependencies" story (though yes, pin your dependencies). There's a deeper pattern here.

Most AI agent setups treat the proxy layer as trusted infrastructure. It's "just" a router — it receives API keys, forwards requests, returns responses. Nobody audits it with the same rigor as the agent framework itself.

But the proxy has the most privileged position in the entire stack. It sees every key, every prompt, every response. If it's compromised, everything downstream is compromised.

This is the same pattern we see in agent security bugs all the time — the boring infrastructure component that nobody watches is exactly where you're most vulnerable.

What To Do Right Now

If you run a LiteLLM proxy:

  1. Check your version: pip show litellm
  2. If on v1.82.7 or v1.82.8: downgrade immediately to v1.82.6
  3. Check for persistence: look for ~/.config/sysmon/sysmon.py and sysmon.service
  4. In K8s: audit kube-system for node-setup-* pods
  5. Rotate everything: every API key, every credential, every token that touched the proxy

If you don't run LiteLLM but use another proxy:

  • Pin your proxy dependencies. Not >=, not ~=. Exact pins.
  • Run your proxy in isolation. Separate container, minimal permissions.
  • Monitor outbound connections. A proxy should talk to LLM APIs and nothing else.

The Uncomfortable Truth

Supply chain attacks on AI tooling are going to accelerate. The AI ecosystem is moving fast, dependencies are deep, and the incentive for attackers is enormous — one compromised package gives you keys to hundreds of thousands of LLM accounts.

LiteLLM got lucky in a weird way: the fork bomb bug made the attack noisy. Imagine a version where the malware was quiet. How long before someone noticed?

For most setups: probably never.

PyPI quarantined both versions within hours. The OpenClaw community posted a docs advisory. LiteLLM's GitHub issue (#24512) was closed as "not planned" by the repo owner (whose account appears compromised). The situation is still developing.

References: The Hacker News, futuresearch.ai, XDA.

Top comments (0)