The LiteLLM attack and the two security layers your AI agent stack is missing
On March 24, 2026, malicious versions of LiteLLM - 1.82.7 and 1.82.8 - were published to PyPI between 10:39 and 16:00 UTC. LiteLLM has roughly 3.4 million downloads a day and sits in 36% of cloud environments. It acts as a universal gateway between AI applications and over 100 LLM providers, which means it has direct access to API keys for OpenAI, Anthropic, Google, Azure, and everything else in your stack.
The attacker group TeamPCP compromised a maintainer account - believed to stem from credentials stolen in the earlier Trivy CI/CD breach - and pushed directly to PyPI bypassing the normal release process. Version 1.82.7 embedded a credential stealer in proxy_server.py. Version 1.82.8 added a second mechanism: a malicious .pth file (litellm_init.pth) that triggered on every Python process startup, whether or not LiteLLM was explicitly imported. SSH keys, cloud credentials, Kubernetes secrets, .env files - everything accessible from that machine was collected, encrypted, and exfiltrated to models.litellm.cloud, a domain with no affiliation to LiteLLM's actual infrastructure.
The packages have since been removed from PyPI. LiteLLM has engaged Google's Mandiant team for forensic analysis of the publishing pipeline.
Two different threats#
Most developers building AI agent infrastructure think about one security layer: known vulnerabilities in the software they deploy. CVEs, CVSS scores, patch availability. This is the threat that NVD, CISA KEV, and tools like Attestd address - a specific software version has a known flaw, and you need to know about it before you deploy or depend on it.
The LiteLLM attack is something different. There was no CVE. The vulnerability wasn't in LiteLLM itself - it was in the publishing pipeline. A legitimate, widely-trusted package was tampered with at the registry level. The installed version looked correct. The package name was correct. The malicious code was designed to evade simple inspection.
These are two separate threat categories:
CVE risk state - does this version of this software have known vulnerabilities? Is it actively exploited? Is a fix available? This is a data problem: public advisory information needs to be synthesized into machine-readable signals your systems can act on.
Supply chain integrity - was this package actually built and published by who you think it was? Has the registry copy been tampered with? This is a trust and provenance problem: you need to know whether what you downloaded is what the maintainer intended to ship.
Neither layer replaces the other. A clean CVE record doesn't tell you the package wasn't tampered with. A clean supply chain doesn't tell you the software itself is free of known vulnerabilities. An AI agent stack without both layers is running partially blind.
If you were affected#
Check now:
pip show litellm | grep Version
If the output shows 1.82.7 or 1.82.8, the damage may already be done. You are not affected if you were running the official LiteLLM Proxy Docker image - that deployment path pins dependencies and did not rely on the compromised PyPI packages.
Rotate every credential that was accessible from that machine. This includes LLM provider API keys, cloud provider tokens (AWS IAM, GCP service accounts, Azure AD), SSH keys, database passwords, Kubernetes tokens, and anything stored in .env files. Don't triage - rotate everything.
Check for the malicious .pth file:
find /usr/lib/python3/site-packages/ -name "litellm_init.pth"
If present, remove it immediately and treat the host as compromised.
Check for persistence indicators. Look for outbound traffic to models.litellm.cloud or checkmarx.zone - neither is affiliated with LiteLLM. In Kubernetes environments, audit kube-system for pods matching node-setup-* and review cluster secrets for unauthorized access.
Purge package caches to prevent reinstallation from cached wheels:
pip cache purge
# or if using uv:
rm -rf ~/.cache/uv
Pin to a known safe version. v1.82.6 is confirmed clean with published SHA-256 checksums in LiteLLM's official security advisory. Pin to it until a later verified release is announced.
What structural approaches actually help#
No single tool stops both threat categories. A serious security posture for an AI agent stack looks like this in practice:
Version pinning and lockfiles - not optional. Unpinned dependencies mean you get whatever PyPI serves at install time. An attacker who compromises a package between your last install and your next build gets in automatically. This is how LiteLLM hit developers who weren't even directly depending on it - it came in as a transitive dependency through agent frameworks and MCP plugins.
Audit transitive dependencies. The LiteLLM attack was first discovered because an MCP plugin inside Cursor pulled it in without the developer knowing. Most developers don't know what their agent frameworks are pulling in beneath the surface. pip-audit, cyclonedx-py, and uv tree are starting points.
Registry monitoring for supply chain signals. Tools like Socket and Sonatype track package integrity and flag suspicious publishes at the registry level. This is the supply chain layer - distinct from vulnerability scanning, operating at a different point in the stack.
CVE risk monitoring for infrastructure components. The web server, database, reverse proxy, SSH daemon, and TLS library your agent interacts with have their own CVE histories entirely separate from package supply chain risk. This is what Attestd covers: structured, deterministic risk state for infrastructure software versions that your agent can query and branch on directly.
These layers operate at different points in the stack. Applying one doesn't substitute for the others.
What Attestd covers today - and what's next#
Attestd addresses the CVE risk state layer: known vulnerabilities in infrastructure software versions, synthesized into machine-readable boolean fields an agent can act on without interpretation. It covers nginx, PostgreSQL, Redis, OpenSSH, Apache HTTPD, log4j, VMware ESXi, Microsoft Exchange, OpenSSL, curl, and more - with significant coverage expansion underway in Q2.
It doesn't currently track supply chain integrity signals. That's a different data problem with different sources, and the LiteLLM attack is exactly the event that makes it the right next thing to build.
In Q2, Attestd is adding a supply chain integrity layer for AI/ML packages - the same ecosystem that makes attacks like this one so high-value. LiteLLM, LangChain, LangGraph, AutoGen, CrewAI, and the major LLM SDKs. Same API surface, second data layer. When a package is flagged as compromised, your agent finds out the same way it finds out a version of nginx is actively exploited - one structured API call.
In the meantime, the CVE layer is live. Free tier, 1,000 calls a month, no credit card required.