LiteLLM Supply-Chain Compromise: An Incident Response Guide

What should LiteLLM users do now?

Determine whether LiteLLM 1.107.0 or an affected container image actually ran in your environment on 21 October 2026. If it did, isolate the system, preserve relevant evidence, rebuild it from a known-good source and rotate every credential the environment could access. Do not treat removal of the package from public registries as remediation for a system that already executed it.

LiteLLM states that all seven PyPI wheels for version 1.107.0 were malicious from 11:39:51 to 13:23 UTC. Docker Hub tags v1.107.0, latest, main-latest and main-stable pointed to a compromised image from 11:46:56 to 14:20 UTC; equivalent GHCR tags were unavailable by 13:51 UTC. The project says earlier versions and its private enterprise release were not affected. Check the official incident record for the complete artifact list and timeline.

Why this incident matters to AI teams

LiteLLM is used as a Python SDK and gateway across multiple model providers. A gateway or developer environment may be able to reach model-provider tokens, cloud identities, source repositories, deployment systems and application data. The incident therefore illustrates a wider risk: a trusted dependency can become an access path into several services at once, even when the application code itself has not changed.

CERT-In describes the event as a targeted software supply-chain compromise. Its advisory explains that malicious files used Python startup mechanisms, so execution could occur when Python initialized without an application explicitly importing LiteLLM. That detail changes triage: finding the package in an environment is not merely a vulnerable-library finding; teams must determine whether Python ran after installation. Read CERT-In advisory CIAD-2026-0053.

Establish exposure from build and runtime evidence

Start with evidence that survives changing registry tags. Search dependency lockfiles, software bills of materials, build logs, package caches, image manifests and deployment records for LiteLLM 1.107.0. For containers, inspect the immutable image digest recorded by the runtime or orchestrator rather than checking only what a floating tag such as latest points to today. The official report identifies the compromised Docker image index as sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e.

• Inventory: identify repositories, CI jobs, laptops, servers and clusters that install LiteLLM or use its images.
• Resolution history: check whether an unpinned dependency or a lockfile refresh could have selected 1.107.0 during the publication window.
• Runtime history: confirm whether Python started in the affected environment or whether an affected container was launched.
• Filesystem evidence: look for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py in relevant site-packages directories. The project cautions that finding one confirms exposure, while not finding one does not prove the environment is clean. See the vendor's exposure checks.

Contain and recover in the right order

If an affected artifact ran, treat the host or container as compromised. Isolate it from normal network access while preserving the logs and metadata your incident-response process requires. The LiteLLM notice warns against beginning with pip commands because starting Python in the affected environment can execute the malicious startup files again. Prefer investigation from a trusted environment and rebuild rather than attempting to clean the running system in place.

• Preserve evidence before replacement: deployment events, process and network telemetry, identity logs, image IDs, package metadata and relevant cloud audit records.
• Rebuild virtual environments, hosts or containers from a known-good artifact. Purge version 1.107.0 from internal mirrors, caches and registries so it cannot be reintroduced.
• Revoke or rotate credentials the affected environment could reach, prioritising cloud and workload identities, CI/CD and registry tokens, model-provider keys, source-control access, database secrets and administrative sessions. Rotation should invalidate the old value, not merely create an additional key.
• Review identity, cloud, source-control and model-provider audit logs for unusual use after the first possible execution time. Expand the review if credentials were shared across systems.

Datadog's analysis reports credential-stealing and remote-access capabilities. StepSecurity provides additional file, process, domain and artifact indicators. Use those indicators as investigative leads and validate them against your own baseline. An indicator match needs contextual investigation; absence of a known indicator cannot demonstrate that no data left the system. Review the independent payload analysis. Consult the detailed recovery guidance and indicators.

Reduce the next dependency compromise

Version pinning limits surprise updates but does not establish that an artifact is trustworthy. Combine exact dependency versions with reviewed lockfile changes, immutable container digests, provenance verification where available and an approved artifact registry. Retain build metadata so responders can later answer which exact wheel or image ran, where and when.

• Use short-lived workload identities and least-privilege service accounts so one runtime cannot expose unrelated environments.
• Restrict outbound connections from build runners and production gateways to required destinations, with usable logs for denied and permitted traffic.
• Separate build, release and production credentials, and prevent long-lived personal tokens from entering shared runners or containers.
• Test a dependency incident playbook that joins engineering, identity, cloud and business owners; package removal alone is not an incident-closure criterion.

Limits and practical takeaways

The reported times above are UTC and should be converted carefully when comparing them with logs. Floating tags may now point to clean images, so current registry state cannot reconstruct a historical deployment. The vendor's investigation was updated as facts developed; consult its canonical incident record before making final scope decisions.

The most useful outcome is an evidence-backed decision for every environment: not present, present but not executed, or executed and handled as a compromise. Record the evidence, containment, rebuild and credential-rotation decisions. This approach applies beyond LiteLLM to any package that executes inside a credential-rich build or AI gateway environment.

This article reflects sources checked on 24 October 2026. Guidance and investigation findings can change. For practical learning, explore CyberDefend Academy's professional learning paths and hands-on labs. Organisations strengthening software supply-chain response can also review our security advisory services.