Englishবাংলা
SubscribeWrite
Latest
Binary search: patterns, templates and common pitfallsDocker's $250 Cloud Sandboxes credit: what it covers and what it does notTwo pointers and sliding window: patterns with examplesArrays and hash maps: the interview patterns you must knowBig-O notation explained: time and space complexity for interviewsSoftware testing basics: the test pyramid and what to testClean code and code review habits that make you a better developerREST API design best practices: URLs, status codes and errors

LiteLLM 1.107.0 was malicious: how to check, clean up and rotate your secrets

On 21 October a compromised release pipeline pushed a credential-stealing LiteLLM 1.107.0 to PyPI and Docker for about two hours. What the malware does, how to tell if you are affected, and the order to clean up and rotate.

••3 min read
Colourful program code glowing on a dark screen

On 21 October 2026, attackers who had stolen developer credentials used LiteLLM's own release pipeline to publish a malicious litellm 1.107.0 to PyPI and to the project's Docker images. The package was live for roughly two hours. If any machine or container installed it, treat that machine as compromised.

This summary follows LiteLLM's incident report and the Datadog Security Labs analysis, with news coverage from The Hacker News and Help Net Security. LiteLLM says some details are still being confirmed, so check its page for updates.

What happened

  • How: the attacker used stolen GitHub CLI credentials of three engineers to run LiteLLM's private release workflow against a look-alike repository, Berri-AI/litellm (the real one is BerriAI/litellm). The official source tag does not contain the malware; the bad build came from the fake repository.
  • When (UTC, 21 October): wheels uploaded to PyPI at about 11:40; Docker images published at about 11:47; PyPI removed the release at about 13:20; affected Docker tags were cleaned up by about 14:20.
  • Where: PyPI litellm==1.107.0, and the Docker tags v1.107.0, latest, main-latest and main-stable (also on GitHub's registry).
  • Safe versions: LiteLLM says all earlier versions are safe. Datadog advises pinning litellm==1.106.2.
  • Not yet known: how the credentials were first stolen. LiteLLM says it suspects a recently patched vulnerability but has not confirmed it. It also says no link has been established to its earlier incident in March 2026.

What the malware does

Three files are dropped into site-packages: cook.pth, cook.py and sitecustomize.py. Python runs .pth files and sitecustomize.py every time it starts, so the code runs even if you never import litellm.

  • Credential stealer: collects cloud keys (AWS, GCP, Azure, Kubernetes, Docker, Vault, Terraform), SSH/GPG keys, Git, npm and PyPI tokens, .env files, shell history, AI provider keys, and browser passwords. It sends them encrypted to a remote server. On a LiteLLM proxy with a database, it also reads the stored provider keys.
  • Backdoor: every hour it fetches an address from a GitHub-hosted file and runs Python code from there. Datadog says the file held only test values, so no second-stage payload was seen.

Removing the litellm package does not remove these files, and running pip or python in that environment runs them again.

Check if you are affected

  1. Search every host, virtualenv, CI runner and container for litellm 1.107.0 (pip show litellm, lock files, image history).
  2. Look for cook.pth, cook.py or sitecustomize.py in site-packages, and /tmp/remote_code_loader.lock.
  3. Check Docker images against LiteLLM's published digest (sha256:1bbcb144…c339e) if you pulled latest between about 11:47 and 14:20 UTC on 21 October.
  4. LiteLLM warns that a missing marker file proves nothing. If 1.107.0 ever ran on a machine with internet access, assume the secrets were stolen.

Clean up, in this order

  1. Do not start with pip install. Any Python start in the affected environment re-runs the malware.
  2. Stop the background Python process, delete the three files and any __pycache__ copies, and remove the litellm-1.107.0.dist-info folder.
  3. Better still, rebuild the virtualenv or image from scratch, pinned to litellm==1.106.2.
  4. From a clean machine, rotate secrets (below).

Rotate

  • Cloud roles and access keys for any machine that ran it, then check CloudTrail (or your cloud's audit log) for use from outside your network.
  • Every LLM provider key held by the proxy, plus LiteLLM master and virtual keys and the database password.
  • GitHub, npm, PyPI and Docker tokens, SSH keys, and anything in .env files or process environments.

Rotate at the service that issued the secret and revoke the old one. Our Railway secrets guide has a longer rotation order.

Lessons for your own pipeline

  • Pin and hash dependencies, and do not auto-update to the newest version the minute it appears.
  • Add a short delay before adopting new releases (a few days) so the community can catch bad ones.
  • Treat developer CLI tokens as high-value secrets, and restrict release workflows to approved repositories and branches.

Update log

  • 25 October 2026: first published from LiteLLM's report, Datadog and news coverage. A CERT-In advisory number reported by one news roundup could not be checked on CERT-In's own site, so we do not rely on it.

Cover photo: Slashme, CC0, via Wikimedia Commons.

Keep reading