What the LiteLLM Hack Means for Every AI-Powered App (Including Your Email Client)

On March 24, 2026, two poisoned versions of the popular Python package LiteLLM appeared on PyPI. Within roughly three hours, versions 1.82.7 and 1.82.8 were downloaded by an unknown number of developers and CI pipelines before PyPI quarantined them. The payload was not subtle: a credential-stealing backdoor designed to exfiltrate every API key, cloud secret, and database password it could find on the infected host.

The vulnerability was discovered in LiteLLM's PyPI package, one of the most popular LLM proxy libraries with over 20,000 GitHub stars. The attack injected malicious code into the package's .pth files, which execute automatically when Python loads the package.

https://x.com/feaborhan/status/2037495423263199702

LiteLLM is not a niche library. It is the de facto open-source "LLM gateway" used by thousands of teams to route requests across 100+ model providers (OpenAI, Anthropic, Azure, Bedrock, Vertex AI) through a single, unified interface. When a package that sits at the chokepoint between your application and every AI provider it talks to gets compromised, the blast radius is enormous.

This article breaks down what happened, why the attack vector is uniquely dangerous, and what every team running AI-powered software needs to do right now.

LiteLLM, developed by BerriAI (a Y Combinator-backed startup), is an open-source Python SDK and proxy server. It abstracts away the differences between LLM provider APIs, letting you switch between GPT-4, Claude, Gemini, Mistral, and dozens more without rewriting integration code. Beyond simple abstraction, it handles routing, load balancing, spend tracking, budget controls, and logging.

For AI-native applications, LiteLLM often has access to every API key in the system. That makes it a uniquely attractive target for supply chain attackers: compromise one dependency, harvest credentials for every model provider a company uses.

The malicious versions used different execution mechanisms, suggesting the attacker was iterating in real time:

https://x.com/simon_willison/status/2037341234654593410

The first poisoned release embedded a base64-encoded payload directly in litellm/proxy/proxy_server.py. The malicious code would execute whenever litellm.proxy was imported, which happens automatically when running the LiteLLM proxy server. This is the most common deployment mode for production environments.

The second release introduced a far more insidious mechanism: a file named litellm_init.pth placed in the Python site-packages directory. This is the detail that caught the attention of AI researchers and security experts alike, including Andrej Karpathy.

The .pth file exploit is alarming because Python automatically executes code in .pth files on interpreter startup, before any imports, before any application code runs, and regardless of whether the compromised package is actually used in the session. Simply having it installed means the payload runs every time Python starts.

Both versions contained credential-harvesting logic that collected environment variables (where API keys, database URLs, and cloud credentials typically live), along with configuration files and other secrets accessible to the running process. The stolen data was exfiltrated to attacker-controlled infrastructure.

Security firms including Snyk, StepSecurity, and Trend Micro traced the attack to a broader campaign attributed to a threat actor dubbed "TeamPCP." This group had previously targeted security-scanning tools, and the LiteLLM attack represented an expansion into developer-facing AI infrastructure.

The campaign follows a pattern: compromise widely-installed packages that run in privileged environments (CI/CD pipelines, production servers) where they have access to the richest credential stores.

Traditional supply chain attacks on web frameworks or utility libraries are serious, but the AI stack introduces compounding risk factors that make incidents like this more consequential:

# Check if your LiteLLM installation is compromised
pip show litellm | grep -i version

# Verify package integrity
pip hash litellm | diff - known_good_hashes.txt

# Check for malicious .pth files
find $(python -c "import site; print(site.getsitepackages()[0])") \
  -name "*.pth" -exec grep -l "import" {} \;

# If compromised: rotate ALL API keys immediately
# OpenAI, Anthropic, Azure, AWS, Google Cloud - everything

For email platforms that integrate with LLM providers, like Maylee's AI reply and classification features, supply chain attacks on proxy libraries represent a critical threat vector. A compromised LiteLLM instance in your infrastructure would expose not just your LLM API keys but potentially your users' email content being sent for AI processing. This is why defense-in-depth strategies with network segmentation, secrets rotation, and package pinning are essential for any production AI deployment.

https://x.com/kaborhan/status/2038021219807576414

LiteLLM's security advisory provides detailed remediation steps and indicators of compromise for affected versions.

AI applications typically hold API keys for multiple model providers, vector databases, embedding services, and orchestration platforms. A single compromised dependency can harvest credentials worth tens of thousands of dollars in compute credits, or provide access to proprietary training data.

LiteLLM is designed to be a centralized proxy, meaning it is intentionally given every key and every routing configuration. It is the single point through which all LLM traffic flows. Compromising it is the equivalent of compromising a load balancer that also stores all the passwords.

The .pth mechanism means the payload runs even if the developer never explicitly imports LiteLLM in a given script. Any Python process on the machine is affected. This broadens the attack surface from "applications using LiteLLM" to "any Python code on the same machine."

Many teams pin to latest or use version ranges in their requirements.txt. Automated CI/CD pipelines that ran pip install litellm during the three-hour window would have pulled the compromised version, built container images with it, and potentially deployed those images to production.

BerriAI's response was swift. They published a detailed security advisory confirming the affected versions, provided indicators of compromise (IoCs), and coordinated with PyPI to quarantine the packages. The advisory recommended treating any host that ran the affected versions as fully compromised and rotating all credentials.

The team also published a clean version (1.82.9+) and began implementing additional safeguards including artifact signing and enhanced release verification.

1. Check your installed version. Run pip show litellm on every machine, container image, and CI runner. If you see 1.82.7 or 1.82.8, assume full compromise.

2. Search for the IoC file. Look for litellm_init.pth anywhere in your Python site-packages directories.

3. Rotate every secret on the affected host. This includes API keys for every LLM provider, cloud credentials (AWS, GCP, Azure), database passwords, SSH keys, and Kubernetes tokens.

4. Audit outbound network traffic. Check logs for connections to domains not associated with your legitimate infrastructure.

5. Rebuild from clean images. Do not simply upgrade the package. Rebuild containers and redeploy from known-good artifacts.

This incident is a wake-up call for any team building on the AI stack. Consider these practices:

• Pin exact versions in all dependency files and lock files.

• Use hash verification (pip install --require-hashes) to ensure packages match expected checksums.

• Run dependency scanning tools (Snyk, Socket, Phylum) that detect suspicious behaviors in new releases.

• Isolate secrets from build environments. Use vault systems rather than environment variables where possible.

• Monitor PyPI feeds for unexpected releases of your critical dependencies.

The LiteLLM incident is a symptom of a structural problem. The AI ecosystem is built on a sprawling web of open-source dependencies, many maintained by small teams, distributed through package managers with limited integrity checks. As AI applications handle increasingly sensitive data and credentials, the incentive for attackers to target this supply chain only grows.

Python's .pth auto-execution mechanism, in particular, has drawn renewed scrutiny. It is a decades-old feature with legitimate uses, but it also represents a powerful and underappreciated attack surface. The Python community is now debating whether to restrict or deprecate this behavior.

For product teams building AI-powered tools, the lesson is clear: your AI dependencies are not just software libraries. They are trust boundaries. Every package that touches your API keys, your user data, or your model routing is a potential vector for compromise. The same rigor you apply to securing your own code must extend to the packages you install.

Tools like Maylee, which let users bring their own API keys (OpenAI, Anthropic, Mistral, Gemini, Grok) rather than centralizing credentials on the platform side, demonstrate one architectural pattern that reduces blast radius. When each user holds their own keys, a single compromise does not expose the entire customer base. Combined with GDPR compliance and a policy of never using customer emails for AI training, this approach reflects the kind of security-first thinking the AI ecosystem needs more of.

The .pth mechanism deserves special attention because it represents a class of risk that many Python developers are entirely unaware of. These files were originally designed for simple path configuration, allowing packages to add directories to Python's import path. But the specification also allows arbitrary code execution via import statements embedded in .pth files.

This means any package that places a .pth file in site-packages gains automatic code execution on every Python interpreter startup, with no import required, no user action needed, and no warning displayed. The Python Packaging Authority (PyPA) and core developers are now actively discussing whether to restrict or deprecate this behavior, but any change would require careful migration given legitimate uses in existing packages.

For security-conscious teams, the immediate mitigation is auditing site-packages for unexpected .pth files as part of container image scanning and CI/CD validation steps. Longer term, the Python ecosystem needs a mechanism to distinguish benign path configuration from executable code in these files.

The LiteLLM attack was caught quickly, limited in duration, and transparently communicated. That is the best-case scenario for a supply chain compromise. But the three-hour window was enough to potentially affect any automated pipeline that happened to update during that period.

The real takeaway is not about LiteLLM specifically. It is about the AI infrastructure layer as a high-value target. As more applications depend on centralized LLM gateways, embedding services, and orchestration tools, these chokepoints become irresistible to attackers.

The convergence of high-value credentials, automated deployment pipelines, and a culture of rapid dependency updates creates a perfect storm for supply chain attacks. Teams building AI-powered products must treat dependency security with the same rigor they apply to their own application code. Pin versions, verify hashes, scan for anomalies, and assume that any package in your dependency tree could be the next target.

Investing in supply chain security is not optional; it is a prerequisite for shipping AI-powered products responsibly.