Malicious LiteLLM release stole keys: rotate secrets if you installed 1.107.0
An attacker published LiteLLM 1.107.0 with credential-stealing malware. The package was live for about two hours on 21 October. LiteLLM asks affected users to treat the environment as compromised and rotate every key.
LiteLLM, a widely used open-source gateway for language models, was hit by a supply-chain attack on Wednesday 21 October. An attacker managed to publish version 1.107.0 with malware that steals credentials and loads remote-control tools. According to the company, the malicious package was live on PyPI for about two hours, and poisoned Docker images were available a little longer.
For leaders, the consequence is easy to state. LiteLLM often sits between internal systems and model providers such as OpenAI, Anthropic and Google, so it has access to API keys and other secrets. If an organisation installed or started the affected version, LiteLLM itself asks that the environment be treated as compromised and that the keys be rotated.
What happened
LiteLLM published an incident report on its own blog on 21 October, signed by, among others, CEO Krrish Dholakia and Director of Security Oliver Jensen. The latest update we read was dated the same day at 20:30 UTC. At that point the incident was contained, but the investigation was still ongoing.
According to the report, seven malicious litellm 1.107.0 packages were on PyPI from 11:39 to 13:23 UTC. On Docker Hub, the tags v1.107.0, latest, main-latest and main-stable pointed to a compromised image from 11:46 to 14:20 UTC. On GitHub's container registry, the same tags were affected until 13:51 UTC. The company says the official 1.107.0 source code on GitHub does not contain the malicious files. The packages were built from a repository the attacker controlled, with a name that resembled the real one.
LiteLLM says customers using its private enterprise release were not affected.
How the attacker got in
The report describes a chain of failures, not a single flaw. LiteLLM had tightened its release process after an earlier incident in March. On the Monday of the same week, the company temporarily expanded release permissions so two engineers could publish daily bug-fix backports for customers.
According to LiteLLM, the attacker had access to three sets of developer GitHub CLI credentials. One belonged to an owner of the GitHub organisation. It was used to disable branch protection, and a modified workflow pointed the release at the fake repository. A third account was used to delete the workflow logs, which limits the investigation.
LiteLLM also writes that it has observed cases where Claude Code embeds a user's GitHub CLI token in a response, and that such tokens can end up in LiteLLM logs when responses are logged. The company believes the attacker got into an internal LiteLLM deployment that was exposed to the internet and took tokens from its logs. How the attacker gained access is not confirmed. LiteLLM suspects a recently patched vulnerability. These are the company's own findings and assessments, and they have not been independently verified.
What affected organisations must do
LiteLLM says organisations are affected if they installed an unpinned version via pip during the PyPI window, or started the listed Docker images during the registry windows. The company recommends pinning to 1.106.2 or another explicit earlier version.
The advice in the report is concrete. Do not start by running pip install in an affected environment, because any Python start runs the malware again. Remove the malicious files, stop the process it started, and preferably rebuild environments and images from scratch. If a machine with outbound internet access ever had 1.107.0 installed, the organisation should assume data was sent out.
After that, everything the machine could reach must be rotated. LiteLLM specifically lists the instance IAM role, all provider keys stored in the LiteLLM proxy database, master and virtual keys, the database password and every secret in the environment of processes on the host.
What leaders should ask now
The first question is whether LiteLLM is in use, including in experiments and internal tools. Development environments often pull the latest version automatically. The second is whether anyone pulls tags such as latest in production instead of fixed versions. Those were exactly the setups that were hit.
The third concerns logging. By LiteLLM's own account, developer tokens ended up in logs from an AI gateway. Logs from such systems can therefore contain more than management expects, and should be protected like secrets.
LiteLLM also says another vulnerability has been fixed in an embargoed release for enterprise customers, with public disclosure scheduled for 27 October. Organisations using the open-source edition should watch for that date.
hogby.ai has not examined the packages itself. The figures and times above come from LiteLLM's report.
Sources and media
Source: LiteLLM.
Illustration: AI-generated with Grok Bot / hogby.ai