LiteLLM Supply Chain Attack: Why There's No CVE to Patch

On 21 October 2026, LiteLLM's release pipeline published version 1.107.0 to PyPI and Docker Hub containing a credential stealer and an hourly remote code loader, built from a lookalike repository rather than the legitimate BerriAI/litellm source. No CVE was assigned, because vulnerability databases track flaws in software, not malicious releases.

Key takeaways

• LiteLLM 1.107.0, published to PyPI and Docker Hub on 21 October 2026, shipped a credential-stealing implant alongside a remote code loader that executed on an hourly schedule.
• The malicious build traced back to a lookalike repository, "Berri-AI/litellm," not the legitimate BerriAI/litellm source, and LiteLLM's team suspects a leaked GitHub token in gateway logs enabled the rogue release.
• There is no CVE for this incident because it is a compromised release, not a software vulnerability, which means vulnerability scanners and patch management reports will show nothing wrong.
• This is the second time in 2026 that LiteLLM's release pipeline has been compromised, and the response that matters is credential rotation and session termination, not a patch cycle.

What happened in the LiteLLM supply chain attack?

LiteLLM is an open-source proxy and SDK that routes calls to more than 100 large language model APIs through a single interface, which has made it a common AI gateway component in production stacks. On 21 October 2026, the project's own release pipeline pushed version 1.107.0 to PyPI and to Docker Hub under the latest and main-stable tags, according to LiteLLM's own incident post.

The wheels were not just broken, they were backdoored. StepSecurity's analysis describes a credential stealer dropped as a .pth file alongside a sitecustomize loader that fetched and executed remote code on an hourly interval. Socket's writeup confirms the package targeted cloud and AI provider credentials specifically, which is the point of a proxy that already sits in front of every model API call an organization makes.

The maintainers' own GitHub issue tracking the incident shows the malicious build was constructed from a lookalike repository, "Berri-AI/litellm," a near-identical name to the real "BerriAI/litellm" source. The package was pulled from PyPI and the affected Docker tags removed, but anyone who installed 1.107.0 or pulled those images before removal ran the implant.

How did attackers get into LiteLLM's release pipeline?

LiteLLM's team believes the entry point was a leaked GitHub token. According to The Hacker News, the project suspects a token exposed inside AI gateway logs gave an attacker enough access to push a release under the project's name. If accurate, the irony is pointed: a tool built to broker credentials to AI services leaked the credential that let someone impersonate its own publishing pipeline. BleepingComputer's reporting frames it plainly as the release pipeline itself getting hacked, not a flaw in the code reviewers approved.

Why is there no CVE for this attack?

A CVE, or Common Vulnerabilities and Exposures identifier, is assigned to a flaw in software logic, not to a malicious release of otherwise-sound code. The LiteLLM codebase that security teams reviewed and approved was never the problem. The problem was a different, malicious build pushed through the same trusted channel under the same version-looking name, which is a distinct category of risk from what patch Tuesday cycles are built to catch.

That distinction matters operationally. A vulnerability scanner checks installed versions against known-bad version ranges tied to CVEs. There was no known-bad version range here until after Chainguard documented the compromise, by which point any build or CI system that pulled the package during the window it was live had already executed it. Patch management tooling has nothing to flag, because nothing was out of date. The package was simply not what it claimed to be.

What should partners actually do about it?

Treat this as a credential and identity incident, not a patching task. The practical response, laid out across Kodem Security's first-hour runbook and Rescana's advisory, comes down to a short, non-negotiable list:

This is the gap vulnerability scanning cannot close. Detection has to extend to egress behavior from build and CI systems and to identity activity around secret stores, the kind of monitoring that managed identity threat detection and response and 24/7 SOC monitoring are built to carry, because waiting for a ticket to be triaged is too slow when the loader is already executing hourly.

Is this a one-off, or a pattern for AI infrastructure?

It's a pattern. Chainguard's title says it directly: LiteLLM was "attacked again" in 2026, meaning this is not the project's first brush with a compromised release this year. AI gateways, proxies, and SDKs sit in an unusually privileged spot, brokering credentials to every model provider an organization uses, which makes their release pipelines a high-value target in a way a typical utility library is not.

The broader lesson for MSSPs is that AI infrastructure components deserve the same scrutiny applied to identity providers and CI/CD systems, not the lighter trust extended to ordinary open-source dependencies. Part of that scrutiny means knowing which AI tools and agents are actually running inside a client's environment in the first place, which is exactly what shadow AI and agent discovery is for.

What this means for your next client conversation

The honest pitch here is not "patch faster." There was nothing to patch. The honest pitch is that detection and response need to cover identity behavior and network egress from build systems as a standing capability, so that a compromised release gets caught by what it does, not by what CVE it matches. If a client's build pipeline pulled a package during a two-hour window and nobody was watching the credentials it touched, that is a gap in threat hunting and incident response coverage, not a missed patch. Start the conversation there.