LiteLLM 1.107.0 hack: check floating tags and your own proxy logs

An attacker got into the release pipeline of LiteLLM, the open source gateway that sits between a company's apps and its AI model providers, and published a poisoned version 1.107.0 on October 21. LiteLLM says the bad package was on PyPI from roughly 11:39 to 13:23 UTC, and that its container images were bad from about 11:46 UTC until 13:51 on GitHub's registry and 14:20 on Docker Hub. LiteLLM says its timeline is still being verified. Wiz counts approximately 49,000 downloads of the malicious version, using ClickPy data.

The payload is three files dropped into the Python library folder. They run every time Python starts, even if the app never loads LiteLLM, and they go after cloud keys, SSH keys, CI secrets, AI tool tokens and the provider API keys stored in the LiteLLM proxy database. LiteLLM calls all earlier versions safe and tells users to pin 1.106.2. Its private enterprise registry was not affected.

Check 1: you may have pulled it without choosing it

Most advice starts with "check whether you installed 1.107.0." Container users can miss that. LiteLLM says the Docker tags latest, main-latest and main-stable pointed at the bad image too, alongside v1.107.0, and its post now also lists the litellm-database and litellm-non_root images on GitHub's registry. Socket confirmed the floating tags on GitHub's registry resolved to the affected image. A deployment set to track main-stable that restarted or scaled during that window could be running the payload with nobody on the team ever typing 1.107.0. Socket's advice is to check the digests of running images, not just the tags in your manifests.

Check 2: your proxy logs may hold the next attacker's way in

LiteLLM's account of how it was breached is the part proxy operators should read twice. It found an unexpected user account on an internal LiteLLM deployment that was reachable from the internet. It suspects a recently patched vulnerability but has not confirmed one. According to LiteLLM, Claude Code can put a developer's GitHub CLI login token into the text of its replies, and a proxy that records full replies will then hold that token in its logs. The team believes the attacker pulled the tokens from that deployment's logs. The attacker held three developers' GitHub credentials, one of them a GitHub organization owner's, and used them to run the release build from Berri-AI/litellm, a lookalike of the real repository.

Any company running its own proxy with full request and response logging can have the same problem: coding assistants and agents pass secrets through the gateway, and the logs keep them. LiteLLM has two controls. Setting turn_off_message_logging: True in the litellm_settings block stops messages and responses going to your logging provider while spend tracking continues. Separately, the "Store Prompts in Spend Logs" setting (store_prompts_in_spend_logs) decides whether request and response content goes into the spend logs table. A value set in the admin UI overrides the config file, so check both places. The setting is under general_settings in the config, and it applies to new logs only. LiteLLM's docs say a retention period is optional, so if you never set one, check what old rows still hold.

This is LiteLLM's second compromise this year. In March, BleepingComputer reports, the TeamPCP group published malicious versions after breaching the Trivy scanner in LiteLLM's build pipeline. Socket told The Hacker News the evidence does not link the two attacks.

Related: Railway secrets breach: what to rotate now and GhostAction and GitHub Actions secrets.