LiteLLM says its release pipeline was compromised and version 1.107.0 shipped credential-stealing malware

TLDR

• LiteLLM says its release pipeline was compromised on 21 October and malicious v1.107.0 reached PyPI and Docker registries.¹³
• JFrog says the payload runs at Python startup, even if an application never imports litellm.²
• LiteLLM says to treat any environment that ran 1.107.0 as compromised and to pin to 1.106.2 or earlier.¹

LiteLLM says its release pipeline was compromised in the early morning of 21 October and pushed v1.107.0, containing compiled malware that steals credentials and loads remote-code execution tools, to PyPI and its Docker registries.¹ The company says the PyPI package was live from 11:39 to 13:23 UTC, the compromised Docker tags (v1.107.0, latest, main-latest, main-stable) pointed to bad images from 11:46 to 14:20 UTC on Docker Hub, and the official source tag on GitHub does not contain the malicious files.¹ It says customers on its private enterprise release were not affected, that all previous versions are safe, and that anyone who installed 1.107.0 or ran the affected Docker images in the window should assume the environment is compromised and pin to 1.106.2 or an earlier explicit version.¹ Wiz puts the PyPI quarantine at 13:20 UTC and the container removals at about 13:53 UTC.³

JFrog says all seven wheels carry three extra files that run at Python startup, steal a broad set of credentials and provide an hourly remote-code execution channel, while the source distribution lacks them, so reviewing source or a Git tag alone can miss the payload.² Wiz says the stealer targets browser, cloud and AI tool secrets and sends them to an attacker-controlled domain impersonating LiteLLM, and that a second-stage loader fetching from a GitHub dead drop was dormant when analysed.³ JFrog likewise found the dead-drop file empty at the time it checked.²

On the cause, Wiz quotes LiteLLM as saying actions were taken through three engineers' GitHub accounts, apparently using stolen GitHub CLI OAuth tokens, with one account triggering the release run and another approving it.³ LiteLLM later said it suspects an attacker reached an internet-exposed internal LiteLLM deployment, possibly through a recently patched vulnerability, and found tokens in its logs; it has not confirmed how the access was gained.³ JFrog calls this the second hijacking of LiteLLM in 2026 and says no evidence currently links it to the earlier March incident, which it attributes to TeamPCP.²

Why it matters: LiteLLM is a widely used gateway to AI model providers, so credentials stolen from environments that installed the build could expose cloud and AI accounts, and JFrog's point that the sdist was clean shows source review alone is not enough.²³