LiteLLM 1.107.0 compromised: are you affected, what to do

LiteLLM says version 1.107.0, published to PyPI, Docker Hub and GHCR on 21 October 2026, carried credential-stealing malware. It says earlier versions were unaffected. If that version was ever installed on a host with outbound internet, LiteLLM says to assume the exfiltration succeeded. Rebuild the environment from scratch, pin 1.106.2 or another earlier release, and rotate every secret that host could read.

Who is affected by the LiteLLM 1.107.0 compromise?

Anyone whose environment installed litellm==1.107.0, or ran an image whose digest matches one LiteLLM lists. The tag name alone does not decide it, because LiteLLM scopes the images by digest and by time window. That includes laptops, CI runners, build caches and servers, not only the machine running the proxy.

The group most at risk is anyone who installs without a pinned version or lockfile, or who deploys from a mutable tag such as latest. LiteLLM says anyone who ran an unpinned pip install or pulled the listed tags in those windows should assume compromise. LiteLLM says the packages were removed from PyPI and the tags repointed or made unavailable, but its report does not address cached or mirrored copies. Its remediation applies if 1.107.0 was installed on a host with outbound internet, so a host that installed it from a cache after the window is still in scope (at our check on 24 October 2026).

You are not affected by this incident if you can show that no machine of yours ever installed 1.107.0 or ran an image with one of the listed digests. Section "Am I affected?" below says what that evidence looks like.

Why is "I deleted the package" not enough?

This is the trap. The malware did not rely on running code when you imported LiteLLM. LiteLLM reports that the release added cook.pth and sitecustomize.py to the Python environment, and that any Python start in that environment runs them again, including running pip. Python's own documentation says import lines in .pth files are executed at start-up and that a sitecustomize module is imported automatically. Datadog adds that deleting the litellm package directory does not remove these files.

Two consequences follow:

1. Uninstalling or downgrading does not undo anything. The files stay, and so does anything the malware already sent out.
2. Running pip uninstall in the affected environment starts Python, which can run the malware again. Isolate first.

Also keep the scope in proportion. The report says the official source tag was not modified and the malicious files were in the published artifacts. It does not say every LiteLLM version, the source code or enterprise customers were affected.

How do I remove it and rotate?

The steps below follow LiteLLM's remediation list, cross-checked against Datadog's. LiteLLM lists deleting the files and reinstalling a pinned version, and says rebuilding images and virtual environments from scratch is better. Datadog's advice is to revert to 1.106.2, remove everything tied to 1.107.0 and rotate from a clean machine. We lead with the rebuild because deleting files by hand can miss whatever you did not know to look for. The two sources agree on the rotation.

How do I clean up if I run LiteLLM myself?

• Isolate the host or runner from the network, and do not run python or pip in the affected environment yet.
• Per LiteLLM: delete cook.pth, cook.py, sitecustomize.py and the matching __pycache__ bytecode from every affected site-packages.
• Per LiteLLM: stop the detached Python process that holds /tmp/remote_code_loader.lock.
• Rebuild virtual environments and images from scratch rather than patching them. Pin litellm==1.106.2 or another explicit release from before the incident, ideally with hashes. If you run a proxy with an Enterprise license, pin 1.106.5 or the patched release for your branch instead (see "What is still moving?").
• From a trusted computer, rotate (see AWS on access keys) the instance or task IAM role, every provider key stored in the LiteLLM database, the LiteLLM master and virtual keys, the DATABASE_URL password, and every secret in the environment of any process on the host.
• Per LiteLLM: in AWS CloudTrail, look for GetCallerIdentity from the instance role around install time, then for the role's credentials being used from outside your infrastructure. Do the same in your other providers' logs.
• Redeploy dependent services with the new secrets and confirm the old ones are revoked at the provider, not just removed from your config.

What if someone else runs LiteLLM for me?

Send them this and keep the answer:

Was litellm==1.107.0 ever installed in any environment that runs or builds our service, or did any of them run a LiteLLM image whose digest matches one in LiteLLM's incident report (Docker Hub, or the GHCR indexes for litellm, litellm-database and litellm-non_root)? Please include copies pulled from a cache or mirror. Please name the lockfile, image digest or pull log that shows it, say whether the environment was rebuilt from scratch, and list which of our keys and secrets were reachable from it and when each was rotated.

If the answer is "we do not know", that is the unknown state below. Rotate what you control.

What do the indicators look like?

For hunting only: the file names above, litellm-1.107.0.dist-info in site-packages, the lock file /tmp/remote_code_loader.lock, and network traffic to the lookalike domain litellm[.]dev that Datadog lists. LiteLLM says finding one of these confirms exposure and that not finding one does not prove the environment was never exposed.

Am I affected?

Was anything exploited?

At our check on 24 October 2026, two primary sources describe the malware. LiteLLM states that it steals credentials and loads remote-code execution tools. Datadog Security Labs analysed the artifacts itself and describes a credential stealer plus a backdoor that polls a GitHub-hosted file hourly for further code. Datadog says that file only held test values, so it observed no further malicious code delivered in the wild. No primary source we found names a victim or reports stolen credentials being used against anyone. The lack of a public report says little about what happened. If the malware reached your host, assume your secrets left it.

How the attackers got in comes from the maintainer alone. Datadog relies on LiteLLM's account for the release mechanics and says it was not yet clear how the credentials were first compromised. LiteLLM's 21 October report said it had not confirmed how the attacker reached its internal deployment. Its update of 23 October, 21:50 UTC says the investigation into the attack chain is complete, and its root-cause record dated 23 October 2026 says a master key for an internal alpha service was committed to a public repository on 27 May and never revoked. On 10 October it was used against that service's API, which returned the GitHub CLI token of an organisation owner. On 21 October that token was used to disable branch protection on the release repository and to dispatch a build from a lookalike fork whose commit exists only there. The record says the first post's suspicion about logs was corrected. Treat all of this as the maintainer's account.

What happened, hour by hour?

All times are UTC, from the maintainer's root-cause record and incident report, at our check on 24 October 2026.

A fork commit can be served under the parent repository's URL, as GitHub documents for forks. That is how a clean official source tag and a malicious build can both be true.

What is still moving?

For another package-registry incident, see the ChainDrop npm worm check, and the other supply-chain and secrets guides cover the rest. If you run other tools in the same week, a checklist that sorts the work by effort helps you order it.

How do I stop the next one from reaching me?

These come from what the incident exposed, and cost little:

• Pin every Python dependency to an exact version with hashes (the wider pinning and lockfile habits apply to npm too), using pip's hash-checking mode, and pull images by digest, not by latest.
• Keep AI gateway keys and cloud roles as narrow as you can. A proxy that holds every provider key makes one bad install very expensive.
• Do not give build machines standing credentials to production.
• Do not read a signed or "provenance" badge as proof of safety; what npm provenance does and does not prove applies to any registry.
• Keep a record of what was installed or pulled and when. This incident was decided by a window of about two and a half hours.