My minute-by-minute response to the LiteLLM malware attack

Who Should Read

Backend/ML engineers who use Python packages as dependencies, or developers interested in open-source supply chain security. An essential reference especially for teams using AI development tool stacks such as litellm, uvx, and Cursor.

Core Mechanics

• On March 24, 2026 at 10:52 UTC, litellm v1.82.8 was uploaded to PyPI with no corresponding GitHub tag. It appeared to be an official release but was actually a malicious package; the last legitimate version was v1.82.6.
• The attack chain was: Cursor → futuresearch-mcp-legacy (v0.6.0) → litellm (v1.82.8) → litellm_init.pth. This meant users could be infected through the dependency chain even without directly installing litellm.
• The core of the malware was the litellm_init.pth file (34KB). A .pth file is a special file that automatically executes every time Python starts, without any import statement. This file was also registered in RECORD (the official package manifest) with its sha256 hash, confirming it was included in the official wheel.
• The malware had three objectives: credential theft, lateral movement within a Kubernetes cluster, and data exfiltration. It attempted to establish persistence by creating ~/.config/sysmon/sysmon.py, but was interrupted by a forced reboot when an 11,000-process fork bomb occurred.
• The discoverer, Callum McMahon, is an ML engineer, not a security expert. Through conversations with Claude Code, he performed journalctl log analysis, confirmed the package re-download in a Docker-isolated environment, contacted the PyPI security team (security@pypi.org), and published a public blog post. Only 72 minutes elapsed from the first symptom to public disclosure.
• Claude Code took only 3 minutes to write the public blog post, create a PR, and merge it. Claude Code directly authored the disclosure post, demonstrating that AI can support not just analysis but also the communication phase.
• The malicious package was live on PyPI for approximately 46 minutes (around 10:52–12:04 before and after public disclosure). Had automated dependency updates run during that window, infection was possible — and in fact, FutureSearch's MCP server pulled that version during that period and was compromised.

Evidence

• "Discoverer Callum left a comment identifying himself as an ML engineer. He noted that 'Claude guided me step by step through contacting the PyPI security team and the time-critical sequence of actions — it was a game changer for a non-security professional.' He also asked the community whether more vulnerability reports from non-experts would be a net benefit or a burden to the security community, to which a realistic counterpoint emerged: 'The problem isn't non-expert reporting itself, but reporting in ways that make triage harder.' A highly upvoted comment highlighted the danger of .pth files: 'Most developers think pip install just puts files on disk and runs them at import time, but .pth files execute every time Python starts, with no import needed. Unlike npm's postinstall hook which runs only once, .pth files run every single time — making them far more persistent.' Concerns were also raised about Claude potentially executing malware by accident. In the transcript, the discoverer explicitly tells Claude 'please don't accidentally run this when downloading in the Docker container,' and a commenter warned: 'LLM agents have no sense of accountability — if they accidentally execute a script, it's a disaster. Sandboxing untrusted code is doable in one or two commands, but you have to be careful about delegating too much to a text prediction machine.' A '24-hour dependency update delay policy' was mentioned across multiple comments as a practical countermeasure against supply chain attacks. Commenters shared concrete experience: 'Many teams use auto-merge Dependabot PRs with no delay, which exposes them even within a 46-minute malicious package window. A simple policy of no package updates within 24 hours of release would have fully prevented this attack — uv already supports this.' There were also proposals for package registries like PyPI to provide real-time event feeds (firehoses): 'Scanners capable of instant detection already exist, but there's no channel to receive updates in real time. If GitHub, npm, and PyPI exposed real-time streams for security analysis, attacks like this could be caught much faster.' It was also noted that enterprise-scale teams need to build all packages from source or use internal mirrors, while for smaller teams, dependency pinning/locking plus a waiting period is the realistic defensive baseline."

How to Apply

• "For projects using uv, apply a 24-hour cooldown to dependency updates. This is an already-supported uv feature that prevents deployment pipelines from automatically pulling new releases immediately after publication, completely eliminating exposure windows like the 46-minute attack window in this case. If you have AI agents connected to production environments (MCP servers, Cursor plugins, etc.), audit the list of packages those agents depend on and pin their versions. Tools like uvx that dynamically pull dependencies at runtime are a particular attack surface, so consider maintaining an internal allowlist and a manual approval gate. When a system becomes unusually slow or shows a sudden spike in processes, you can use Claude Code or similar AI coding tools to jointly analyze journalctl logs, htop output, and package manifests (RECORD files). Even without security expertise, explicitly asking the AI to 'consider the possibility of malicious behavior' can accelerate early incident response significantly. Establish an isolation verification procedure for suspected malicious packages. Re-download the suspect package inside a Docker container, check the file list and whether any .pth files are present, and read the contents without executing anything. As in this case, emailing the PyPI security team (security@pypi.org) with evidence (file hashes, infection path) can result in a quarantine action."

Code Example

# How to inspect a .pth file without executing it (Docker isolated environment)
docker run --rm --network none python:3.11 bash -c "
  pip install litellm==1.82.8 --dry-run 2>&1 | head -20
  pip download litellm==1.82.8 -d /tmp/pkg --no-deps
  cd /tmp/pkg && unzip -l litellm-*.whl | grep .pth
"

# Read the .pth file contents (without executing it)
docker run --rm --network none python:3.11 bash -c "
  pip install litellm==1.82.8
  cat $(python -c 'import site; print(site.getsitepackages()[0])')/litellm_init.pth
"

# Configure 24-hour dependency update delay in uv (uv.toml)
# [pip]
# upgrade-package-delay = '24h'

# List all .pth files in installed packages
python -c "
import site, os
for sp in site.getsitepackages():
    for f in os.listdir(sp):
        if f.endswith('.pth'):
            print(os.path.join(sp, f))
"

Terminology

Related Resources

• Original post: My minute-by-minute response to the LiteLLM malware attack
• FutureSearch LiteLLM attack disclosure post
• claude-code-transcripts (Simon Willison's Claude conversation visualization tool)
• PyPI security report email