What happened
On October 21, 2026, a supply-chain attack put a malicious LiteLLM release, version 1.107.0, on PyPI and in the project’s official Docker images. All seven wheels carried a credential stealer and a backdoor that run at the start of every Python process, even one that never imports LiteLLM (SafeDep analysis). PyPI removed the release in under two hours; the infected images stayed up to two and a half hours (LiteLLM’s incident report).
This is the second incident of its kind this year. On March 24, 2026, attackers uploaded LiteLLM 1.82.7 and 1.82.8 with a similar stealer straight to PyPI, outside the project’s normal release workflow (LiteLLM’s incident timeline). They used a publishing token stolen from LiteLLM’s own CI pipeline, where a compromised version of the Trivy security scanner was running (Sola Security). LiteLLM then rotated maintainer accounts and promised a safer CI/CD process. In October, the malware emerged from LiteLLM’s own release pipeline.
LiteLLM says its private registry for enterprise customers was not affected (GitHub issue #47826). On Hacker News, the reaction was blunt: users counted the incidents and asked what everyone had migrated to.
Why an AI gateway is a prime target
In a supply-chain attack, nobody breaks into your systems directly. Attackers compromise a component you trust, such as a library, a package or a build pipeline, and let your own installs deliver the malware.
An AI gateway is an especially valuable component to poison. It holds the API keys for every model provider you use, and every prompt and response passes through it. The October stealer went straight for that: it targeted the LiteLLM proxy database, where provider keys and model settings are stored, along with SSH keys, cloud and CI/CD credentials, and tokens for AI coding tools. A second payload checked in every hour to download and run new code.
Removing the package does not undo the damage: whatever the stealer sent is already in the attacker’s hands.
What actually failed: the release process
It is tempting to blame open source, but that misses what happened. LiteLLM’s public code was clean: the v1.107.0 tag on GitHub contains no malware. The attacker pushed ten commits to a lookalike repository, Berri-AI/litellm, one hyphen away from the real BerriAI/litellm. LiteLLM’s own release workflow then built version 1.107.0 from it (StepSecurity).
The build provenance even recorded the wrong source repository, yet nothing stopped the release. The wheels went to PyPI, the images went to Docker Hub and GHCR, and the latest tags moved to the infected build. LiteLLM says stolen credentials of three engineers were used to override branch protection, start the release and approve it. It believes the attacker took those tokens from the logs of its own internet-exposed internal LiteLLM deployment; how the attacker got into that deployment is still unconfirmed (LiteLLM’s incident report).
Many projects pull LiteLLM with open-ended version ranges, so a bad build reaches users the moment it is published.
Open source itself is not the problem. What matters is who controls the release and what every build must pass before it ships.
Choosing a LiteLLM alternative: five questions to ask
Before you pick a gateway, or decide to stay with the one you have, ask how it gets to production. Each question below comes with what a good answer looks like and how OptScale AI answers it.
- Who can ship a release? Only the vendor’s own team, from its official source, through a controlled pipeline.
- OptScale AI: our own engineering team at Hystax, which has built enterprise software since 2016. The core platform is closed-source, so only our engineers change its code and build its releases, and Enterprise customers can audit the source.
- What must a build pass first? A mandatory QA gate, with no way to publish around it.
- OptScale AI: a strict QA process; no release ships until it passes.
- How do updates reach you? Through a controlled rollout the vendor is responsible for, never through whatever a floating latest tag points to today.
- OptScale AI: with SaaS, there is nothing to install; we run and upgrade the platform for you. On-premises licenses receive updates on the schedule set by the plan: quarterly, monthly or continuous.
- Where do your provider keys live? In one place, inside the gateway, rather than copied to every laptop and CI runner. The trade-off: a breached gateway exposes every key at once, so it needs the strongest protection.
- OptScale AI: admins connect providers once in the Admin Console. Teams, apps and agents get governed access instead of holding provider keys. Provider keys are encrypted at rest and never shown again after setup, secrets are masked in logs and traces, and every change to a provider connection is logged. Credentials also travel inside AI traffic, so admins can enable a Secrets guardrail that detects API keys, tokens and passwords and blocks them before they reach a provider.
- Can you run it inside your own perimeter? On-premises or air-gapped deployment lets you control what the gateway can reach.
- OptScale AI: yes. On-premises licenses run on your own cluster; an air-gapped installation is available from the Medium cluster plan, and your content never leaves your environment.
Beyond release safety, OptScale AI gives teams one governed control point for every model they use. Its AI gateway connects to OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, Mistral, Ollama, vLLM and other providers, with routing, fallbacks, guardrails and tracing in one place (documentation).
Switching is straightforward. Applications that use the OpenAI-compatible API move to OptScale AI by updating their connection settings.
If you run LiteLLM today
Whatever you decide long term, do these now:
• Check laptops, CI runners and containers for LiteLLM 1.107.0, and for images pulled on October 21 through the the v1.107.0, latest, main-latest or main-stable tags.
• On any affected host, follow the recovery steps from StepSecurity and LiteLLM, then pin version 1.106.2 or an image digest.
• Rotate every secret those hosts could reach, including all provider keys stored in the LiteLLM proxy database.
• Block the attacker domain litellm.dev at your DNS or egress firewall.
• Pin exact versions everywhere and wait a day or two before adopting new releases.
If this incident has you rethinking your gateway, Book a Demo to see how OptScale AI fits your setup, or open the Live Demo to explore it on your own.
