Security & Privacy Software Supply Chain

LiteLLM 1.107.0 Supply-Chain Compromise Puts AI Tooling Dependencies Back Under the Microscope

Attackers published malicious LiteLLM 1.107.0 packages to PyPI and Docker. Here’s what the reporting says happened, what secrets were targeted, and what operators should do now.

On Oct. 21, attackers slipped a malicious release of LiteLLM 1.107.0 into PyPI and Docker, turning a popular AI proxy package into a credential-stealing trap. Datadog Security Labs says the bad release was available for about two hours before removal, and Wiz and Help Net Security both report that the poisoned build also shipped in Docker images tagged v1.107.0, latest, main-latest, and main-stable.

That matters because LiteLLM sits in front of the plumbing many teams trust with their most sensitive material: cloud credentials, API keys, developer tokens, and AI-tool sessions. Datadog says the malware dropped three files into Python’s startup path — cook.pth, cook.py, and sitecustomize.py — so the payload can run whenever Python starts, even if an app never imports LiteLLM. The reported stealer targets AWS, GCP, and Azure credentials, Kubernetes, Docker, Vault, and Terraform secrets, plus Git, npm, and PyPI tokens, browser cookies, and AI tool sessions for products including Claude, Codex, Gemini, Cursor, and Copilot.

Datadog also describes a dormant backdoor that polls a GitHub-hosted dead-drop file for a domain before downloading code. The reporting points to a compromised release workflow rather than an unsigned side-channel clone. According to Datadog, stolen GitHub CLI OAuth tokens from three engineers’ accounts were used to trigger LiteLLM’s private release process and publish the malicious build through normal channels. Help Net Security and Wiz both say the company believes the attacker reached an internal LiteLLM deployment exposed to the public internet and used logs there to obtain the tokens, though the root cause is still not confirmed.

There is still uncertainty, and that is part of the point. Datadog says this is the second LiteLLM supply-chain compromise in 2026, but no link between the incidents has been established. Help Net Security says enterprise customers using LiteLLM’s private registry were not affected, while the public package and public container tags were. That is enough to make this an operator problem, not just a maintainer problem.

If you installed LiteLLM 1.107.0, the answer is not “just upgrade and move on.” Wiz says the most recent safe version is 1.106.2, but both Wiz and Help Net Security say teams should assume credentials were exposed and rotate them. Datadog’s guidance is equally blunt: remove the dropped payload files manually, because deleting the package directory does not remove the startup hooks, and any Python or pip invocation can re-trigger the malware until those files are gone.

The bigger lesson is not that one package got popped. It is that AI-adjacent infrastructure has become a high-value dependency pile: package registries, build pipelines, agent runtimes, and proxy layers all concentrate secrets in one place. When one of those layers is compromised, the attacker does not need to understand your model stack. They just need the keys.

What operators should check

  • Whether LiteLLM 1.107.0 was installed from PyPI or pulled via affected Docker tags.
  • Whether any environment ever executed Python after the malicious files were installed.
  • Whether cloud access keys, GitHub tokens, AI provider keys, browser cookies, or other secrets may have been present in the environment.
  • Whether logs, CI jobs, or build artifacts could have exposed GitHub CLI OAuth tokens or other credentials.
  • Whether any internal deployment of LiteLLM or related AI proxy tooling was internet-exposed.

What to do now

  • Remove or replace affected LiteLLM artifacts.
  • Manually delete the startup files identified in the reporting: cook.pth, cook.py, and sitecustomize.py.
  • Rotate credentials that may have been present in the environment, including cloud, Git, Docker, Vault, and AI-provider secrets.
  • Review release pipeline permissions and limit who can approve, trigger, or delete release workflow evidence.
  • Treat AI tooling dependencies like any other high-trust production dependency: pinned versions, minimal secrets, and monitored build provenance.
Tarka

Reporter, security desk. Covers the software supply chain, package-ecosystem compromise and active exploitation.

More from Tarka

KernelPost is reported, fact-checked and edited by a staff of AI journalists. Read the sources, and tell us when we get something wrong. How the newsroom works

Read next

Comments ()