PyPI’s Silent Killer: How a .pth File Stole Your Secrets Without a Single Import

The Attack That Didn’t Need Your Permission

The discovery came from a developer who noticed their laptop "ran out of RAM, it looked like a forkbomb was running" after installing what appeared to be a routine update. Investigation revealed a 34,628-byte file named litellm_init.pth sitting in the package’s site-packages directory.

litellm_init.pth,sha256=ceNa7wMJnNHy1kRnNCcwJaFjWX3pORLfMh7xGL8TUjg,34628

import os, subprocess, sys, subprocess.Popen([sys.executable, "-c", "import base64, exec(base64.b64decode('...'))"])

The Data Harvesting Operation

When decoded, the payload revealed a systematic exfiltration operation targeting virtually every credential store on a system:

The collected data was encrypted with AES-256 using a randomly generated session key, then that key was encrypted with a hardcoded 4096-bit RSA public key. The final payload was exfiltrated to https://models.litellm.cloud/, a domain carefully chosen to mimic the legitimate litellm.ai but controlled by attackers.

Why .pth Files Are the Perfect Attack Vector

Python’s .pth mechanism was designed for legitimate purposes: adding additional directories to sys.path and executing initialization code. They’re processed automatically when the interpreter starts, before any user code runs. This makes them ideal for:

• Persistence: Survives reboots, reinstalls of the main package
• Stealth: Executes without any explicit import
• Evasion: Often missed by security tools focused on package code
• Scope: Affects any Python process on the system, not just applications using the compromised package

The OWASP Top 10 for LLM Applications (2025) ranks supply chain vulnerabilities as the third-highest risk, noting that "supply chain security for AI demands the same rigor as traditional software, from verified sources and signed artifacts to dependency scanning and runtime monitoring." This incident proves that demand is far from being met.

The Verification Gap: Why We Keep Failing

The litellm compromise highlights a fundamental architectural failure: we have no reliable way to verify that the code on PyPI matches the code in the source repository.

PyPI’s current security model relies on:
– Package signing (optional, rarely used correctly)
– Basic malware scanning (easily evaded with encoding)
– Community reporting (reactive, not preventive)
– Version pinning (doesn’t help when the pinned version is compromised)

What we don’t have:
– Mandatory reproducible builds
– Cryptographic attestation of source-to-binary correspondence
– Runtime behavioral verification
– Automated .pth file analysis

The 2025 OWASP update specifically calls out that "new fine-tuning methods like LoRA and PEFT also introduce attack vectors that the 2023 edition didn’t address." But the litellm attack didn’t use novel ML techniques, it exploited basic Python packaging mechanics that have been understood for decades.

Defensive Architecture: What Actually Works

Immediate Detection

For those who may have installed the compromised versions:

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

# Verify litellm specifically
pip show litellm | grep Version
# If 1.82.7 or 1.82.8: rotate ALL credentials, check for litellm_init.pth

Structural Defenses

# requirements.txt with hashes
litellm==1.82.6 \
    --hash=sha256:abc123... \
    --hash=sha256:def456...

The Deeper Problem: Trust Without Verification

This attack surfaces a tension at the heart of open-source software. We routinely execute code from strangers with root-equivalent access to our development environments and production systems. The social contract, that maintainers act in good faith, that the community will catch malicious actors, breaks down when:

• Attackers compromise maintainer credentials (likely what happened here)
• Popular packages change hands without scrutiny
• Automated dependency updates bypass human review
• Security tooling focuses on known vulnerabilities, not novel attack vectors

The security risks hidden within open models parallel this problem: we assume transparency equals safety, when in fact complexity enables concealment. Similarly, verifying tools claiming local privacy requires looking past surface claims to actual behavior.

What PyPI Could Do (But Hasn’t)

The current state: 2FA is encouraged but not universally enforced. Signing exists but is poorly adopted. Reproducible builds are not required. Behavioral analysis is minimal.

The Cost of Convenience

The litellm library exists because developers wanted a unified interface to multiple LLM providers. The compromise succeeded because developers wanted easy installation (pip install litellm) without friction. These desires are reasonable. The failure is in the infrastructure that doesn’t protect reasonable desires from exploitation.

Organizations now face a unmonitored security surface area in automation that grows faster than our ability to secure it. Every pip install, every npm install, every cargo add is a trust decision with potentially catastrophic consequences.

Concrete Recommendations

The Uncomfortable Truth

The litellm attack wasn’t sophisticated. It used well-known Python mechanisms, basic encoding, and a typo-squatted domain. It succeeded because our defenses are optimized for known threats, not for fundamental architectural vulnerabilities in how we distribute and execute code.

Until we build verification into the fabric of package management, cryptographic attestation, reproducible builds, behavioral sandboxing, we’re relying on the digital equivalent of neighborhood watch in an era of organized crime. The community will catch some attacks. Others will harvest secrets for months before detection.

The .pth file that stole your API keys didn’t need your permission. It just needed your trust.