AI security · LLM · AI agentOther industries (software / AI tooling (LLM gateway library))
Datadog reports that release 1.107.0 of LiteLLM, a library with about 23 million weekly downloads, went out poisoned on PyPI and as Docker images tagged v1.107.0, latest, main-latest and main-stable.
Source [1] securitylabs.datadoghq.com · 21 Oct 2026 · “LiteLLM supply chain compromise: What you need to know” ↗
Adoption stage: Production — A named organisation runs it in day-to-day operations.
Summary
Datadog reports that release 1.107.0 of LiteLLM, a library with about 23 million weekly downloads, went out poisoned on PyPI and as Docker images tagged v1.107.0, latest, main-latest and main-stable. The attackers ran LiteLLM's own private release workflow with GitHub CLI OAuth tokens stolen from three engineers, shipping a credential stealer that runs on every Python start plus a second-stage RAT backdoor. The PyPI release went live at 11:39 UTC, was quarantined at 13:20 UTC, and the Docker images were removed at 13:53 UTC — roughly two hours of exposure.
Kenny's take
The library was poisoned through the project's own private release workflow; what was breached was three engineers' tokens, not the code. Any deployment that pulls the latest Docker image was exposed for those roughly two hours. This take weakens if sources beyond Datadog confirm a narrower blast radius.
AI draft · approved by Kenny
Analysis
What happened (vendor-reported, according to Datadog): a supply-chain compromise of an LLM tooling library on 2026-10-21. Who: LiteLLM as the publisher and its downstream users as victims; attacker not named. Vector: stolen GitHub CLI OAuth tokens from three engineers used to run the private release workflow. Impact: a credential stealer and RAT shipped in a release of a library with about 23 million weekly downloads, live for about two hours.
Control: not stated in the source. Datadog lists only after-the-fact remediation (remove files, revert to 1.106.2, rotate credentials from a clean machine, audit logs); it does not say which preventive control would have stopped the release.
For the pattern ai-supply-chain-security, this is evidence about the attack surface, not about a defence adopted by an operator. The stage is set to production because the attack ran through the library's real release channel, not a lab setup; the source names no downstream operator that was hit.
Facts from the source
- F1According to Datadog Security Labs, the PyPI package
litellmversion 1.107.0 and Docker images taggedv1.107.0,latest,main-latestandmain-stableon GHCR and Docker Hub were compromised. [1] - F2According to Datadog, the malicious release was published to PyPI at 11:39 UTC, PyPI quarantined it at 13:20 UTC, and the affected Docker images were removed at 13:53 UTC — "approximately two hours before being removed". [1]
- F3According to Datadog, "attackers used stolen GitHub CLI OAuth tokens from three engineers' accounts to launch LiteLLM's private release workflow"; the attacker is not named. [1]
- F4According to Datadog, the library had "about 23 million weekly downloads". [1]
- F5According to Datadog, the payload was "a credential stealer that runs whenever Python starts" plus "a second-stage remote access trojan (RAT) backdoor". [1]
- F6Datadog's remediation steps: remove
cook.pth,cook.pyandsitecustomize.pyfrom site-packages, revert to version 1.106.2, rotate all affected credentials "from a clean machine", and audit logs for use of exposed credentials. [1]
Organisations: LiteLLM, PyPI
Counterpoint — verification notes
Codex checked each sentence against the source and searched for counter-evidence. Verdict: Codex check · partly supported.
- Other sideLiteLLM’s October 23 canonical investigation says PyPI was quarantined by 13:23 UTC, GHCR tags were unavailable by 13:51 UTC, and Docker Hub tags were removed or repointed at 14:20 UTC. It also says the attacker changed the private release workflow to build from a malicious fork. [2]
- Other sideLiteLLM confirms the incident and lists separate affected windows for PyPI, Docker Hub, and GHCR; it says its private enterprise release was unaffected. [3]
5 sentence-level checks
- analysispartly-supported: LiteLLM’s downstream users were victims. — The source establishes publication of compromised artifacts, but does not identify downstream users who installed or ran them.
- takepartly-supported: 뚫린 곳은 코드가 아니라 엔지니어 3명의 토큰이었다. — Token theft is supported, but the source does not establish that code was untouched. LiteLLM’s later investigation says the attacker changed the release workflow.
- takepartly-supported: latest 태그의 Docker 이미지를 그대로 받아 쓰는 배포 환경이라면 그 약 두 시간이 곧 노출 시간이다. — Exposure depends on pulling or running the compromised image during the affected interval. LiteLLM reports different intervals by registry, with Docker Hub’s lasting until 14:20 UTC.
- takepartly-supported: What was breached was three engineers’ tokens, not the code. — Token theft is supported, but the source does not establish that code was untouched. LiteLLM’s later investigation says the attacker changed the release workflow.
- takepartly-supported: Any deployment that pulls the `latest` Docker image was exposed for those roughly two hours. — This omits the condition that the compromised image had to be pulled or run during the affected interval. LiteLLM reports different intervals by registry, with Docker Hub’s lasting until 14:20 UTC.
Sources
- [1] securitylabs.datadoghq.com — “LiteLLM supply chain compromise: What you need to know” original
- [2] docs.litellm.ai counter-evidence (Codex)
- [3] docs.litellm.ai counter-evidence (Codex)
Keep reading
Stay in the loop.