Make Better
List your asset
AI infrastructure supply-chain security

LiteLLM 1.107.0 Compromised: Check Versions and Recover

•Make Better Editorial

LiteLLM 1.107.0 shipped malicious PyPI wheels and Docker images. See the exposure windows, how to check your deployments and the vendor's recovery guidance.

LiteLLM disclosed on October 21, 2026 that its public release pipeline was compromised and distributed malicious version 1.107.0 through PyPI and official container registries. The incident is contained at the distribution level, but installing or running an affected artifact may have exposed cloud credentials, AI-provider API keys and other secrets. Removing the package from public registries does not clean machines that executed it. This is a supply-chain incident involving released binaries, not a newly announced capability of the LiteLLM API.

Which downloads were affected?

According to LiteLLM's incident report, all seven PyPI wheels for litellm 1.107.0 were available from 11:39 to 13:23 UTC on October 21. Official Docker Hub tags v1.107.0, latest, main-latest and main-stable pointed to compromised content from 11:46 to 14:20 UTC. The vendor also identifies affected GHCR image variants and digests. These time windows describe public distribution, not the time at which every customer installed or executed the artifacts. LiteLLM says earlier versions and its separate private enterprise release were not affected.

Important distinction

A clean GitHub source tag is not evidence that the corresponding released wheel or container was clean. The vendor and independent analysts say the malicious artifacts were built from an attacker-controlled lookalike source repository.

Why the impact extends beyond the gateway

The malicious build contained code designed to collect credentials and provide a mechanism for remote execution. Independent StepSecurity and Datadog analyses describe Python startup hooks that could execute even when an application did not explicitly import LiteLLM. For teams using the gateway as a central connection to multiple models, one affected environment may have access to several upstream providers and cloud services. That makes incident scope dependent on the secrets and permissions reachable from each affected machine, not just on whether a LiteLLM endpoint received traffic.

Practical response for affected teams

  1. Inventory Python environments, lockfiles, build logs, container deployments and registry caches for litellm 1.107.0 or the affected image digests and floating tags during the reported windows.
  2. Treat any host that executed an affected wheel or container as compromised. Preserve appropriate forensic evidence and isolate the workload using your incident-response process.
  3. Follow LiteLLM's official cleanup and rebuild guidance. The maintainer currently recommends pinning to 1.106.2 or an explicitly older version, rather than trusting a floating tag.
  4. Rotate credentials the affected host could access, including AI-provider keys, cloud roles, database passwords and CI secrets; review provider and cloud logs for suspicious use.
  5. Check mirrors, cached images and automated dependency updates so the withdrawn release cannot be reintroduced. Keep watching the vendor's incident page for revised findings.

LiteLLM specifically cautions against beginning remediation by running pip inside an affected environment: Python startup may execute the malicious hooks again. Security teams should use the vendor's detailed recovery instructions and rebuild from known-clean environments. Indicators such as unexpected startup files can help establish exposure, but their absence is not proof that a host was unaffected. Teams that merely use older pinned versions should still confirm their actual deployed artifact rather than relying on the version named in a repository file.

What is confirmed and what remains uncertain

Make Better analysis

The high-confidence facts are the affected release, distribution windows, malicious functionality and registry takedown. LiteLLM's October 21 update describes abuse of developer GitHub credentials and a lookalike repository, but says the initial access to its internal deployment is still under investigation. Avoid assigning an attacker identity or claiming a complete root cause. The decision for operators is simpler: establish artifact exposure and rotate reachable credentials if the malicious version ran.

FAQ

Questions people ask

Does installing LiteLLM 1.107.0 mean my API keys were stolen?

Treat an environment that executed the affected 1.107.0 wheel or container as compromised, according to LiteLLM's October 21 incident guidance. The malicious build could collect secrets accessible to that host, including provider credentials. Actual exposure depends on execution, network access and permissions; a missing indicator does not prove safety. Investigate logs, rebuild cleanly and rotate keys that the host could reach.

Were LiteLLM Docker latest and main-stable tags affected too?

Yes, for a limited period on October 21, 2026. LiteLLM reports that Docker Hub tags latest, main-latest and main-stable, along with v1.107.0, pointed to compromised images from 11:46 to 14:20 UTC. Check the image digest actually pulled or run, not only the tag visible today. Those tags were subsequently repointed, which does not repair previously started containers.

Is the LiteLLM 1.107.0 source tag on GitHub safe to inspect?

The vendor says the official v1.107.0 GitHub source tag did not contain the malicious files, while the distributed PyPI wheels and affected containers did. Analysts traced the published artifacts to a lookalike source repository used in the compromised release workflow. Inspecting the official source tag therefore cannot establish that a wheel installed on October 21 was safe; verify installed artifacts and deployment history.

What LiteLLM version should a team use after the incident?

LiteLLM's October 21 guidance recommends pinning the public package to version 1.106.2, or another explicit version published before the compromised release, while remediation continues. Rebuild affected environments and rotate exposed credentials rather than only downgrading in place. This is time-sensitive vendor guidance, not a permanent version recommendation; check the current incident report before choosing a future upgrade.

Bottom line

LiteLLM 1.107.0 was a confirmed public software supply-chain compromise. The malicious release has been withdrawn, but teams that executed affected artifacts should investigate the host, rebuild from clean sources and rotate reachable credentials. Follow the maintainer's ongoing updates rather than assuming the investigation is finished.

Sources & useful resources