LiteLLM explains its poisoned release: an unrevoked key, an owner-level token and a relaxed approval rule

Update, November 5, 2026: On October 30, LiteLLM published what it is changing after the incident: release approval now sits with one dedicated account tied to an office device, owner work moves to separate accounts that cannot be used through tokens or the gh command-line tool, and GitHub audit logs now feed alerting. Secret scanning, an identity-aware proxy for internal systems and an independent check of published packages are due between November 15 and December 31; some token changes run to January 31, 2027. LiteLLM's incident report also now warns that the malicious 1.107.0 images carry a valid signature from the old signing key. Separately, LiteLLM disclosed an unrelated critical flaw on October 27 (GHSA-w4c7-34wj-hqm8) that affects Enterprise-licensed proxies only; this changes the safe version for those customers (see below).

LiteLLM has published a root-cause report for the malicious version 1.107.0 that hit PyPI and Docker on October 21, 2026: an access key leaked in a public repository in May was never revoked, and it led the attacker to an owner-level GitHub token. Microsoft released detailed detection guidance the same day, October 23. If any system installed 1.107.0 or ran an affected Docker image, rebuild it and rotate its credentials from a clean machine; if not, the lessons on key revocation and token scope still apply to your own pipelines.

What happened, in plain English

LiteLLM is an open-source "AI gateway": a server that sits between a company's applications and AI providers such as OpenAI or Anthropic, so apps call one endpoint and the gateway holds the provider keys. Many developers also install it as a Python library.

On October 21, 2026, a booby-trapped release, 1.107.0, was published to PyPI (the Python Package Index, where pip install downloads from) and to LiteLLM's official Docker images. It ran as soon as Python started on the machine — even if no one used LiteLLM — and quietly collected passwords, cloud keys, SSH keys and AI provider keys. LiteLLM says the bad files were live for about two hours.

On October 23, LiteLLM explained how it happened, in a report it calls "the canonical source of truth":

1. On May 27, 2026, a configuration file containing the master key for one of LiteLLM's internal systems (its Agent Platform) was committed to a public GitHub repository. The file was removed about three hours later, but the commit stayed in the public history until October 22 and, in LiteLLM's words, "key revocation did not occur for the master key."
2. On October 10, the attacker used that key and found, inside the platform's responses, a GitHub login token belonging to an owner of LiteLLM's GitHub organization.
3. With that token, the attacker stole the tokens of two more engineers, and on October 21 used all three to redirect the release process to a look-alike repository, approve the release, and delete the records.

An analogy: you lose an office key, put a new sticker on the door, but never change the lock. Months later, someone walks in and finds the master badge in a drawer.

This replaces LiteLLM's first theory that the token had leaked from its own request logs.

Are you affected? What to do now

You may be affected if, on October 21, 2026, any machine, build job or deployment:

• installed litellm==1.107.0 from PyPI (live 11:39–13:23 UTC), or an unpinned litellm in that window;
• pulled or restarted the Docker Hub or GitHub Container Registry images tagged v1.107.0, latest, main-latest or main-stable (Docker Hub until 14:20 UTC; GHCR until 13:51 UTC).

Not affected: systems pinned to earlier versions. LiteLLM says its private Enterprise registry was not affected. If you have never used LiteLLM, there is nothing to do.

How to check

• Search lockfiles, build logs, pip/uv caches, internal mirrors and container images for litellm 1.107.0. Microsoft stresses the caches and mirrors.
• Check whether any container ran image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e (published by LiteLLM).
• Look in the Python library folder (site-packages) for cook.pth, cook.py, an unexpected sitecustomize.py, or litellm-1.107.0.dist-info, and in /tmp for remote_code_loader.lock or .pc_once_* files. LiteLLM notes that not finding them does not prove a system is clean.
• Check DNS and proxy logs for www.litellm[.]dev (the real site is litellm.ai). Microsoft Defender users can look for the exposure ID TVM-2026-0003 and detections named Trojan:PyPI/LiteLlmSupplyChain.
• Do the check with trusted tools from another system. Both LiteLLM and Microsoft warn that running python or pip in an affected environment re-runs the stealer.

If you were exposed, in this order

• Isolate the host and stop the background Python process holding /tmp/remote_code_loader.lock.
• Rebuild environments and images from scratch, pinned to a known-good version — LiteLLM names 1.106.2 or another explicit version published before the incident — and preferably deploy by image digest rather than a tag. Deleting the litellm folder is not enough: the startup files live outside it. If your proxy runs with an Enterprise license, do not stop at 1.106.2: the October 27 advisory (CVSS 10.0, no CVE) is fixed only in 1.103.10, 1.104.8, 1.105.6 and 1.106.5; LiteLLM says open-source deployments without a license are not affected by it.
• From a clean machine, rotate everything the host could reach: cloud instance or task roles, AI provider keys stored in the LiteLLM proxy database, LiteLLM master and virtual keys, the DATABASE_URL password, Git, SSH and package-registry tokens. Microsoft adds: revoke active sessions too, because rotating a password does not always end a live token.
• On AWS, review CloudTrail for GetCallerIdentity calls around install time and for your role's credentials used from outside your network.
• If you verify LiteLLM image signatures: releases from 1.106.3 (October 24) onward, and the backports 1.105.4, 1.104.6 and 1.103.8, are signed with a new cosign key. Update verification policies, or they will fail. A valid signature from the old key proves nothing: LiteLLM says the malicious 1.107.0 images carry one.

For everyone running a build pipeline, the root cause is a checklist on its own: revoke any secret the moment it is committed publicly (rewriting history does not un-leak it), scope service tokens to the minimum, and do not relax release approval rules without a compensating control.

The expert view

Root cause: three ordinary failures, chained. Nothing here required a software vulnerability. A leaked credential was cleaned up cosmetically but not revoked; a non-human system held a human owner's broadly scoped GitHub OAuth token; and the release gate, normally tied to an approver on a physical office device, had been relaxed earlier in the same week so that any two engineers could trigger and approve. Each is a common shortcut. Together they turned one forgotten key into signed, official packages.

Why the controls failed. LiteLLM did have branch protection and two-person approval. Both assume the two people are distinct and uncompromised. Once an attacker holds several engineers' tokens, separation of duties collapses. LiteLLM notes that the attacker, already an owner, could have changed the rules directly, and believes separate tokens were used to avoid noisy audit-log entries. The attacker also rehearsed: throwaway CI branches on October 10 and 12 harvested secrets via workflows that were deleted minutes later — eleven days before the release. In its October 30 post, LiteLLM says the controls it added after an earlier supply-chain incident in March 2026 (trusted publishing, signing, immutable tags, pinned Actions) "worked as designed" but could not stop an attacker who was an organization owner.

What LiteLLM is changing. The October 30 list targets each link of the chain: release approval back on a single dedicated, device-bound account (done); owner accounts that cannot authorize OAuth apps or be driven by tokens, with alerts on any token activity (alerting due November 15); secret-scanning alerts that close only once revocation is confirmed (due November 30); automations moved off human tokens to GitHub Apps or short-lived, minimal-scope tokens (due January 31, 2027); and a verifier outside GitHub that compares published PyPI and Docker artifacts with the tagged source and can pull mismatches automatically (due December 31). Most items are still in progress or planned, and the post gives no new guidance to users.

Why AI gateways are prime targets. Microsoft's analysis shows the payload specifically queried LiteLLM's own database tables for stored provider credentials and model settings, alongside the usual developer secrets, cloud metadata credentials, browser data and MCP (Model Context Protocol) configuration files used by AI coding tools. A gateway concentrates every model API key a company has, which makes it worth a patient, multi-stage operation.

The execution trick. The package dropped a .pth file and a sitecustomize.py, two legitimate Python mechanisms that run code at interpreter startup (MITRE ATT&CK T1546.018). Microsoft observed the collector firing on Windows when someone ran an unrelated pip install. A Unix-only loader polls a "dead drop" file on GitHub to learn where to fetch more code; Microsoft found it empty, so no second stage was confirmed, but it can be re-armed while the process runs. Stolen data is encrypted with an embedded public key before upload, so network inspection will not reveal what was taken.

Severity in context. No CVE or CVSS score exists; malicious-package incidents are usually tracked as malware advisories. The window was short and the community spotted it about 20 minutes after publication, which limits reach. But for any host that ran it, impact is total credential exposure, and floating tags like latest meant some deployments took the bad image without anyone changing a version.

Still unknown. Who the attacker is (no one has made an attribution), how many installs occurred, and whether stolen credentials have been used; neither LiteLLM post published since answers these. LiteLLM says it "believe[s]" it has traced every token the attacker could reach, and its incident report says it believes the private half of the old signing key was also exposed. Its October 24 release also removed the eMudhra root certificate authority from its trust bundles; as of November 5, LiteLLM has not explained the link, if any, to this incident.

Official sources

• LiteLLM — Oct 21, 2026 incident: attack chain (root-cause report, October 23)
• LiteLLM — What we are changing after October 21 (October 30)
• LiteLLM — incident report with exposure checks and cleanup steps (updated October 30)
• GitHub advisory GHSA-w4c7-34wj-hqm8 — separate critical flaw on Enterprise proxies (October 27)
• Microsoft Security — Inside the LiteLLM 1.107.0 supply chain compromise (October 23, IOCs and hunting queries)
• GitHub — LiteLLM v1.106.3 release notes (new cosign key, eMudhra CA removal)
• GitHub issue BerriAI/litellm#47826 — original report
• Socket — LiteLLM attack timeline
• Coverage: The Hacker News — Leaked LiteLLM master key let attackers steal GitHub tokens and hijack release pipeline