The LiteLLM Breach
This is either extremely good timing or extremely bad. I will go with good.
LidorMachluf
I need some intelligence
I'll find the documented procedure first.
Baden's image is the clean v1.106.2 build (digest 7294b90f…), built before the compromise began. Next I'll check inside the running container and the host for IOCs, avoiding running Python in the container.
Updated analysis: Baden is clean
I connected through pxe and pct exec and ran read-only checks on Baden and Claude .
I changed nothing. I found no sign of compromise on either.
Baden (Production)
| Check | Result |
|---|---|
| Image on the host | One litellm image, ghcr.io/berriai/litellm:main-latest = sha256:7294b90f…, which is the clean v1.106.2 digest |
| Image build time | 2026-10-21 09:31Z, about 2 hours before the first poisoned build and about 2h15m before the Docker tags were repointed (11:48Z) |
Infected digests (1bbcb144…, c00f9d92…, 7b00e91c…) |
Not present on the host |
| Container | Created 2026-10-23 03:07Z, two days after the tags were yanked; running 22 hours, healthy |
| Installed litellm | litellm-1.106.2.dist-info inside the container |
cook.pth, cook.py |
Not found |
sitecustomize.py |
Three copies, all from ddtrace and opentelemetry, which are normal for this image. None sit at the site-packages root, where the malware installs its copy |
/tmp markers (.pc_once_*, remote_code_loader.lock, .pc_sq_*) |
Absent in the container and on the host |
| Processes | Only the litellm proxy. No orphaned python process with cwd / |
| Container logs and host journal (since 10-19) | 0 hits for litellm.dev, letters9813 or privcollect |
The infected image was never on Baden, and the clean image predates the compromise. This is also not a case of the container merely being clean today: the stored image is v1.106.2.
Claude (Development)
No litellm containers or images. The Docker copy of the stack isn't deployed there, so there is nothing to check.
Limits of what I checked
- I didn't search network logs for
litellm.devlookups (UniFi, DNS). The image evidence makes that unnecessary, but it's the extra step if you want certainty. podman eventsrejected my time filter, so I have no direct pull timestamp. The digest evidence covers that gap.- I did not check other hosts: davros, eros (stopped), alex, or the Latitude workstation. The workstation had no litellm and no IOCs earlier.
Verdict
Not compromised. No secrets need rotating. ANTHROPIC_API_KEY and SF_LLM_API_KEY were never exposed to the malicious build. Your layered defences weren't what saved you here. The deployed image is clean because it predates the attack, so it was luck of timing plus having no auto-update.
What I'd still change
The exposure comes from the floating main-latest tag in three files. A Dockhand redeploy during those five hours would have pulled the stealer. Pin by digest in deploy/stack-podman.yml:421, deploy/stack-docker.yml:277 and docker/compose/ai.yml:121:
image: ghcr.io/berriai/litellm@sha256:7294b90f868c5c38c99b83021c7ba46f9b439e95f8e32964c925c7d2563a03f7 # v1.106.2
This is the same rule you already apply to SPIDERFOOT_TAG. Digest pinning won't catch a poisoned release, as the thread points out, so also don't adopt new litellm versions on release day. Adding egress filtering on sf-litellm would block the exfiltration channel too. I haven't edited the files, since SpiderFoot is under review elsewhere. Say the word when you're recovered and I'll apply the pins.
No breach. Moving on
#enoughsaid