Security briefs

Was my team affected by the LiteLLM 1.107.0 supply chain attack?

Published 26 October 2026Updated 26 October 2026

A poisoned litellm 1.107.0 sat on PyPI for about two hours on 21 October 2026. If any machine, CI runner or container installed it, treat every secret that Python process could read as stolen.

What happened

On 21 October 2026, LiteLLM's release pipeline published a malicious litellm 1.107.0. PyPI served the wheels from 11:39 to 13:23 UTC. The Docker tags v1.107.0, latest, main-latest and main-stable served the bad build from 11:46 to 14:20 UTC. An attacker-controlled fork produced both (LiteLLM, 21 October). Datadog counts it as the second LiteLLM supply chain compromise this year.

The wheels drop cook.pth, cook.py and sitecustomize.py into site-packages. Python runs them on every start, even if your code never imports LiteLLM (Datadog, 21 October). The stealer collects cloud credentials, AI provider keys, SSH and GPG keys, browser logins and shell history. It also reads LiteLLM_CredentialsTable from the proxy database and sends the encrypted haul to www.litellm[.]dev/healthcheck (Wiz, 21 October). A second file polls a GitHub dead drop every hour. That file only ever held test values (Datadog).

LiteLLM's root cause post (23 October) starts with the master key of an internal LiteLLM Agent Platform service, committed to a public repository on 27 May and never revoked. On 10 October that key returned an organization owner's GitHub token. On 21 October the attacker used it to override branch protection and ran the release from Berri-AI/litellm, one hyphen away from the real BerriAI/litellm.

Who is affected

• Anyone whose pip install of LiteLLM resolved to 1.107.0 between 11:39 and 13:23 UTC on 21 October, pinned or not.
• Anyone who pulled or started the Docker image v1.107.0, latest, main-latest or main-stable between 11:46 and 14:20 UTC.
• CI runners, build servers and laptops, not only the proxy host.

LiteLLM says all earlier versions are safe, and that Enterprise customers on its private registry were not affected.

What to check now

1. Search the filesystem first. Starting Python or pip in a suspect environment runs the payload again (LiteLLM). A hit confirms exposure, and no hit proves nothing.

   find / \( -name cook.pth -o -name cook.py -o -name 'litellm-1.107.0.dist-info' \) 2>/dev/null
   find /tmp -maxdepth 1 \( -name '.pc_once_*' -o -name remote_code_loader.lock \) 2>/dev/null

2. Check cached images and lockfiles for the bad build.

   docker images --digests --no-trunc | grep -E '1bbcb1443bc9|bd1aeee419ea|56b74573eed6'
   grep -rn --include='requirements*.txt' --include=poetry.lock --include=uv.lock litellm . | grep 1.107.0

3. Search DNS, proxy and egress logs since 11:39 UTC on 21 October for litellm.dev and letters9813/pythonclient-test.
4. On any match, kill the daemon holding /tmp/remote_code_loader.lock, rebuild images and virtualenvs from scratch and pin litellm==1.106.2.
5. Rotate from a clean machine: the instance or task IAM role, every provider key in the proxy database, the master and virtual keys, the DATABASE_URL password and any secret in a process environment on that host.
6. Look for stolen credentials in use. Wiz saw AWS role credentials from CI runners and Kubernetes nodes tested with sts:GetCallerIdentity about four and a half hours after exfiltration (Wiz, 21 October). Check CloudTrail for that call from the role around install time, then for any use of the role from outside your network.

   aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetCallerIdentity --start-time 2026-10-21T11:39:00Z

What should have been in place

• Exact versions with hashes. pip install --require-hashes refuses a build whose hash nobody recorded, and images pinned by digest skip moving tags.
• A delay on new releases. A day of waiting would have missed a build that lived for about two hours.
• Default-deny egress for the proxy and CI runners. LiteLLM's security director said on 24 October that blocking unexpected outbound traffic covers malicious releases and exfiltration.
• Scoped, short-lived credentials. LiteLLM names keys that were too broad and an exposed key that was never revoked.
• Release workflows locked to approved source repositories. Socket found the bad build's provenance named Berri-AI/litellm.

Questions people ask

Digiton's production review reads where your keys and secrets live and what a poisoned dependency could reach, and the checks it runs are on the vibe coded app audit page.

Sources

1. LiteLLM, incident post, 21 October 2026, read 26 October 2026. https://docs.litellm.ai/blog/security-incident-oct-21-2026
2. LiteLLM, the attack chain behind the v1.107.0 release, 23 October 2026, read 26 October 2026. https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
3. LiteLLM security director, comment on GitHub issue 47826, 24 October 2026, read 26 October 2026. https://github.com/BerriAI/litellm/issues/47826
4. Wiz, LiteLLM Compromised, Steals Credentials, 21 October 2026, read 26 October 2026. https://www.wiz.io/blog/litellm-compromised-steals-credentials
5. Datadog Security Labs, LiteLLM supply chain compromise, 21 October 2026, read 26 October 2026. https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-docker/
6. Socket, LiteLLM PyPI package and Docker images compromised, 21 October 2026, read 26 October 2026. https://socket.dev/blog/litellm-compromise
7. Aikido, LiteLLM compromised again, 21 October 2026, read 26 October 2026. https://www.aikido.dev/blog/litellm-compromised-infostealer-rat
8. Help Net Security, LiteLLM hit by second supply chain attack this year, 22 October 2026, read 26 October 2026. https://www.helpnetsecurity.com/2026/10/22/litellm-compromised-supply-chain-attack-pypi-docker/
9. PyPI, litellm release history, read 26 October 2026. https://pypi.org/project/litellm/#history

More security briefs

All security briefs