TechAtelier

CYBERSECURITY · OCTOBER 26, 2026

LiteLLM supply-chain compromise: protecting Python and Docker deployments

An official release can become malicious when its publishing pipeline is compromised. Here's how to assess LiteLLM 1.107.0 exposure and respond without re-triggering the payload.

What happened?

On October 21, 2026, LiteLLM's release pipeline was compromised. The PyPI package litellm==1.107.0 and several officially published container images contained malware intended to steal credentials and enable remote code execution.

LiteLLM reports affected PyPI wheels were available between 11:39 and 13:23 UTC and compromised Docker images between 11:46 and 14:20 UTC. The affected artifacts were removed or repointed. This does not mean every LiteLLM release was compromised.

Which environments should be checked?

  • Python environments that installed litellm==1.107.0, including unpinned installations during the incident window.
  • Containers that ran v1.107.0, latest, main-latest or main-stable during the affected interval.
  • CI/CD jobs that downloaded and executed affected artifacts while having access to credentials.

Floating Docker tags may now point to clean images. The present tag target cannot establish whether an older compromised image previously ran. Review deployed digests and deployment history.

Why the malware was dangerous

Microsoft analyzed Python startup mechanisms involving .pth files and sitecustomize.py. An application did not need to explicitly import LiteLLM: simply launching Python in an affected environment could execute the payload.

LiteLLM's subsequent investigation traced the publication compromise to privileged GitHub credentials and a release workflow redirected to an attacker-controlled lookalike repository. Trusted publishing controls can be undermined when the underlying release process is compromised.

Response checklist

  1. Isolate affected environments and preserve evidence. Do not start with pip install or launch Python inside a suspected environment.
  2. Inventory executed versions, image digests and release history. Check the vendor's indicators including litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. Their absence does not prove safety.
  3. Rebuild virtual environments and container images from verified sources. LiteLLM initially recommended pinning to a verified earlier release such as 1.106.2.
  4. Rotate secrets that could have been accessed: AI provider API keys, GitHub tokens, cloud identities, environment variables and database credentials.
  5. Investigate unusual authentication events and misuse of credentials; monitor vendor guidance for updates.

Reducing supply-chain exposure

Pin application dependencies and artifact hashes where practical; avoid floating container tags in production; minimize CI/CD token permissions and lifetime; separate build and release approvals; record deployed digests; maintain a component inventory and a credential-rotation procedure.

TechAtelier's takeaway: upgrading is not the same as verifying trust. Provenance, least privilege and recovery procedures are essential parts of routine operations.

Sources

LiteLLM — October 21 incident notice · LiteLLM — October 23 attack-chain report · Microsoft Security — Python startup analysis.