LiteLLM 1.107.0: A Poisoned Release Built From a GitHub Token That Leaked Into Logs

The attacker did not break LiteLLM's build. They found the keys to it in a log. LiteLLM, the open-source gateway many teams use to call AI models, disclosed that on 21 October its release pipeline was compromised and a malicious version 1.107.0 was pushed to PyPI and Docker Hub. The package carried a credential stealer and a remote-access backdoor. LiteLLM says the attackers got past multiple independent security controls, including hardening put in place after an earlier incident in March.

The exposure window was short, a few hours. What it took from the machines that ran it may not be.

What LiteLLM says happened

Per The Hacker News's report of LiteLLM's disclosure, which several security vendors corroborate, the unpinned-install window on PyPI ran from about 11:39 to 13:23 UTC, and Docker image pulls were affected from about 11:46 to 14:20 UTC. Anyone who installed or ran the image in that period should assume compromise. LiteLLM reports that the attacker:

Held developer credentials. Three sets of developers' GitHub CLI credentials, one of which could run workflows.
Used a temporary permission change. Release permissions had been widened on 19 October for two internal engineers.
Removed the brakes. An organisation owner's token was used to disable branch protections and force-push changes.
Got a signed, trusted artifact. A workflow pointed at a lookalike repository, so the poisoned artefacts were signed and published through the normal path.

How the attacker first got the credentials is LiteLLM's hypothesis, not a confirmed finding. It suspects that GitHub CLI OAuth tokens leaked into its logs, because an AI coding tool may have embedded users' tokens in response bodies that were then logged, and that an unexpected, innocuously named user account on an internet-exposed internal deployment gave the attacker access to those logs. LiteLLM does not know how that deployment became public and speculates about a recently patched vulnerability.

What the malware does

The write-ups from LiteLLM and from security vendors including Socket, StepSecurity, Wiz and Chainguard describe a credential stealer that collects system, browser, developer, cloud and AI tool secrets and posts them to a lookalike domain, plus a background component that periodically fetches and runs code from an attacker-controlled source. One vendor reports that it loads whenever any Python process starts, even if LiteLLM is never imported. LiteLLM says a second stage on Linux and macOS was reachable through a GitHub dead drop that was taken down around 13:30 UTC.

LiteLLM also reports observed abuse. About four and a half hours after exfiltration, attackers validated AWS instance-role credentials taken from CI runners and Kubernetes nodes, in activity that matched the abuse of AI-model access, including checks of Bedrock model lists. In a few environments they enumerated IAM and other account resources.

What is not known

How the exposed deployment came to be public and how the attacker first reached it.
Whether this is linked to the earlier March attack. Socket found no evidence of a link but does not rule one out. Whether credentials stolen then helped here is unknown.
The number of victims. Nobody has published how many systems ran 1.107.0.
The last safe version. Vendors list different versions, so use LiteLLM's own incident report rather than a summary here.
A CVE. One vendor reports there is none, since this is a compromised release, not a vulnerability.

Two lessons about secrets

Logs are a place secrets go

A token that appears in a request or response body will appear in whatever logs that traffic. An AI coding assistant or gateway makes this easy to do by accident, because it handles long, free-form text that can include credentials a user pasted in. Scrub known secret patterns before logging, restrict who and what can read logs, and treat an exposed log store as exposed credentials.

A temporary permission is still a permission

Release rights were widened on 19 October for two engineers, and the compromise followed two days later. Time-box exceptions, review them when they expire, and require approval from a second person for branch-protection changes, so that one stolen owner token cannot switch the protections off.

What to do

Find out whether you ran 1.107.0. Check lockfiles, container images and CI caches for the version, particularly any build that installed LiteLLM without pinning on 21 October.
If you did, isolate and rebuild. LiteLLM's guidance is to remove the version, isolate the host, hunt for the malicious files, block the exfiltration domain and investigate whether the second stage ran. Rebuild rather than clean if it executed.
Rotate everything reachable. Cloud keys and instance-role credentials, SSH and GPG keys, API keys for AI providers, GitHub and registry tokens, and the credentials stored in the LiteLLM proxy's own database. Replace the credential at the provider first, then update the places that use it.
Check cloud logs for use. Look for sign-ins and API calls from unfamiliar sources since the morning of 21 October, including model-listing calls and IAM enumeration.
Pin and verify. Pin exact versions and hashes for dependencies and base images, and build from your own mirror or with a delay so a freshly published release is not installed minutes after it appears.
Audit your own pipeline. Search logs for tokens, limit what workflows can use, restrict force-pushes and branch-protection changes and review any permission that was widened temporarily.

The handover

A rotation this wide produces a stack of new credentials that must reach the people who deploy them. Keep each value out of the repository, the pull request and the incident channel, and send it once, to the one person who needs it.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a supply-chain security or logging tool. It cannot tell you whether you installed 1.107.0, scrub tokens from logs, protect a release pipeline or rotate your provider keys. Use your package, CI and cloud tooling for that, and a one-time link for the moment one person gives another a new credential.