What happened
On October 21, 2026, LiteLLM disclosed that its release pipeline had been compromised and that version 1.107.0 was published through PyPI and official container registries with credential-stealing malware and remote-code execution capability. All seven PyPI wheels for litellm 1.107.0 were available from 11:39:51 to 13:23 UTC. Docker Hub tags v1.107.0, latest, main-latest and main-stable resolved to compromised image digest sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e from 11:46:56 to 14:20 UTC. The project says its private enterprise registry was not affected and identifies litellm 1.106.2 as the version to pin after affected environments are rebuilt or cleaned.
LiteLLM says malicious actions used three developer GitHub accounts, apparently through stolen GitHub CLI OAuth tokens, to alter and approve the private release workflow. JFrog identified cook.pth, cook.py and sitecustomize.py as the injected startup files; the stealer posted to www.litellm.dev and the loader used /tmp/remote_code_loader.lock. JFrog also published the dead-drop URL raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt and the run-once marker /tmp/.pc_once_72129118c59f5636c0bb. The cited sources did not establish how the GitHub CLI OAuth tokens were obtained.
The affected component was the open-source LiteLLM AI gateway and Python package, version 1.107.0. The cited sources did not identify any underlying AI model or model version as part of the compromise. Exposure depended on operators installing the affected wheel or pulling affected container tags during the published windows. Python startup hooks mechanically ran credential theft and started an hourly remote-code loader; the cited evidence does not establish any model-directed action. Attribution posture: LiteLLM and JFrog name no threat actor, and responsibility for the compromise remains unresolved. The cited source did not publish the specific operational detail described as The token-theft mechanism remains unresolved.
Why this matters now
LiteLLM commonly operates beside model-provider API keys, cloud workload identities, database connection strings and proxy master keys. The malicious package therefore occupied a privileged aggregation point rather than an ordinary developer dependency. A short publication window does not make the risk small when automated builds, floating container tags and continuous deployment can distribute an artefact across many environments before a registry removes it.
The compromise defeats source-centric assurance. The official source tag did not contain the malicious startup files, while the built wheels and container images did. Organisations that approved the release by reviewing the repository, software bill of materials generated from source, or source-distribution archive may have obtained false reassurance. Closure requires verification of the exact artefact executed, not confirmation that the upstream repository now looks clean.
Python processed the injected startup hooks whenever the interpreter started in the affected environment, even if application code never imported LiteLLM. That widens the execution population to CI runners, administrative commands, health checks and unrelated Python processes. Mutable tags also mean teams may have received the malicious image without explicitly selecting version 1.107.0, increasing the importance of registry and runtime evidence.
The decision for security leaders
Declare a security incident for every environment where the affected wheel or container executed. Package removal closes distribution, not credential theft, arbitrary code execution or persistence already triggered on a host.
Authorise credential rotation according to reachability rather than waiting for confirmed exfiltration. The stealer targeted broad secret classes, and absence of its marker file does not establish that collection failed.
Require artefact-level provenance before restoring LiteLLM. Validate wheel contents and immutable image digests, prohibit floating production tags, and separate source approval from built-artefact verification. Before authorising a return to normal dependency installation, require a documented inventory of where the affected release was resolved, built, installed, or executed. Assign named owners to verify credential rotation and downstream exposure, check for recurring loader activity, and record the evidence required to close each affected environment. Keep deployment exceptions time-bound and explicitly approved.
Evidence of closure
- An immutable inventory identifies every affected wheel, image digest, host, container and CI execution.
- Rebuilt environments contain none of the published startup files, lock paths or marker artefacts.
- Credential owners attest replacement of every secret reachable from each affected execution context.
- Cloud and provider logs show no unexplained post-exposure use of replaced credentials from external infrastructure.
The Security.io assessment
The evidence supports high confidence that malicious official artefacts executed credential theft and installed a remote-code loading path. It does not establish how many organisations pulled or ran them, whether the hourly loader retrieved secondary code, or which stolen credentials were subsequently used.
A clean repository tag is not evidence of a clean deployment in this incident. The source and built artefacts diverged, exposing a control gap in organisations that attest dependencies from repositories while deploying registry-produced binaries or containers.
Registry removal and token revocation are containment milestones, not closure. Enterprise closure depends on execution evidence, forensic rebuilds, credential replacement and review of cloud, source-control, package-registry and AI-provider logs for activity originating outside expected infrastructure.
Questions for the morning meeting
- Can the organisation identify every environment that installed LiteLLM 1.107.0 or pulled an affected mutable tag?
- Which credentials, identities and data stores were reachable from each affected execution context?
- Can security rebuild affected environments without invoking the compromised Python interpreter?
- Who can authorise emergency rotation of AI-provider, cloud, database and software-publishing credentials?