AI Dependency Risk After LiteLLM 1.107.0: What One Bad Release Put at Stake

On Oct. 21, a malicious LiteLLM release reached PyPI and Docker, aimed at the API keys AI startups funnel through it. The incident shows how one popular dependency can hold every model key a company has, and what founders can decide in advance.

On Wednesday, October 21, 2026, a poisoned release of LiteLLM, the 1.107.0 build of an open-source Python proxy many developers use to send requests to dozens of AI model providers, shipped with malicious code on PyPI and in its official Docker image, according to Aikido Security. The payload was built to collect the very keys the proxy exists to manage. For founders, it is a clean case study in dependency risk: for any team that pulled the bad version, a package chosen for convenience became a single point of failure for its model accounts.

Where it stands: A GitHub issue tracking the incident logs the bad upload arriving on PyPI at 11:39 UTC and gone by 13:23 UTC, and Aikido later wrote: “Update: PyPI has now quarantined version 1.107.0.” TechCrunch reported that LiteLLM disclosed the compromise in a post on X that afternoon.

What happened to LiteLLM on Oct. 21?

An attacker got a poisoned build into LiteLLM’s official distribution channels. Aikido reported that the attacker “injected malicious code into its published Python wheels on PyPI,” and added: “The official Docker image for the same version is also compromised.” PyPI is the main public registry for Python packages; a wheel is the prebuilt file that installers download.

Oct. 21 (UTC) What the record shows
11:39-11:40 PyPI receives the 1.107.0 upload (GitHub issue)
By 13:23 PyPI has removed 1.107.0 (GitHub issue)
Afternoon LiteLLM discloses on X (per TechCrunch)
Later update Aikido: PyPI quarantined the version

How the bad build was produced is still a reported finding, not a company statement. The person who opened the GitHub issue wrote: “Root cause: the release was built from the lookalike repo Berri-AI/litellm .” Aikido described the mechanism as a packaging step that let the attacker add files “into the compiled wheels without touching the source repository.” That detail matters to founders: by Aikido’s account, reviewing LiteLLM’s public source code would not have revealed the added files.

Why does an AI proxy concentrate so much dependency risk?

Dependency risk is the chance that third-party code your product relies on causes harm. For most packages, a compromise exposes whatever that one machine can reach. An AI gateway is different, because its whole job is to hold credentials for many providers at once.

Aikido’s list of what the payload went after makes that concrete. It included “The contents of the LiteLLM database directly, including all rows from LiteLLM_CredentialsTable (stored API keys for every provider) and LiteLLM_ProxyModelTable (model configurations).” It also listed “Developer tool credentials and configuration files for Claude Code, Claude Desktop, Cursor, GitHub Copilot, Windsurf, Gemini CLI, Amazon Q, Codex CLI, Aider, Continue, HuggingFace, and others.”

TechCrunch summarized the malicious code as an information stealer “that targeted cloud credentials, passwords, and AI service credentials,” plus a remote access trojan, a tool that lets an outsider run commands on the infected system.

What Aikido says was targeted What a team would need to replace
LiteLLM’s stored provider keys Every model-provider key in the proxy
AI coding-tool credentials and configs Tokens for those tools on affected machines
Cloud credentials (per TechCrunch) Cloud access keys on the host

The trade-off is real in both directions. Routing all model traffic through one proxy gives a startup one place to log usage, switch providers and enforce limits. It also means one bad version can reach every key at once. Neither choice is wrong; the decision is about which risk the team is set up to manage.

How do pinning and lockfiles change the outcome?

By the GitHub issue’s timestamps, the upload arrived at 11:39 UTC and was gone from PyPI by 13:23 UTC. Whether a startup was exposed through PyPI depended largely on whether anything installed the newest version during that window.

Pinning means naming an exact version of each dependency in your build files instead of accepting whatever is newest. A lockfile records the exact versions, and ideally the file hashes, that were tested, so every later install reproduces them. Teams that pinned LiteLLM to an earlier release and rebuilt from a lockfile would not have pulled 1.107.0 automatically; teams with loose version ranges, or Docker builds tagged “latest,” could have.

The same applies to images. Aikido said the official Docker image for 1.107.0 was compromised too, so referencing an image by its fixed digest rather than a moving tag is the container version of pinning.

Pinning has a cost: someone has to bump versions deliberately, read release notes and test. That is the ownership question covered in our patch day runbook from Oct. 21, where PHP and Node.js fixes had to be pulled in quickly on the same day this bad release had to be kept out.

Are AI coding agents widening the exposure?

They raise the number of installs that happen without a human choosing them. Help Net Security reported an estimate attributed to Bloom that “agents on a typical endpoint install about 70 packages a month, and close to 350 on developer machines, not counting dependencies.”

That is Bloom’s estimate, not a measured industry figure, but it points at a policy gap. If an AI coding assistant can add or upgrade packages, the startup’s pinning and review rules need to apply to the agent’s changes as well, and those changes should go through the same pull-request review as a person’s.

Scanning your own code with AI tools, the subject of our look at AI security scanning, does not help here: Aikido says the injected files never touched the source repository.

What should you rotate, and how fast?

If any machine installed 1.107.0, treat everything Aikido listed as exposed. One trap is assuming that deleting a secret revokes it. Fireworks AI, writing about its own separate incident, put it plainly: “Removing a stored secret alone does not invalidate the underlying credential.” It added: “Third-party credentials require action with their issuing providers.”

So the order is: create a new key at each provider, swap it into every service that uses it, then revoke the old one at the provider. Our startup secrets management runbook walks through that sequence in detail.

Old keys tend to outlive the incident. GitGuardian’s 2026 report found that when it retested a set of leaked secrets in January 2026, “the validity rate was still above 64%.” OWASP’s secrets guidance explains part of why: “Key rotation is a challenging process when implemented manually, and can lead to mistakes,” so it recommends automating rotation where possible.

Which vendor settings cap the damage before it happens?

Spending limits and scheduled rotation reduce how much a stolen key is worth. OpenRouter’s documentation says: “We recommend setting a credit limit on every key,” warning that “A key with no limit lets a leaked key or a runaway agent spend your entire balance, including any auto top-ups.” Anthropic’s help center suggests rotating “on a consistent schedule (for example, every 90 days).”

The stakes are rising with the volume of AI keys in circulation. GitGuardian’s count of AI service secrets found in public GitHub commits reached 1,275,105 in 2025, “up 81% year over year.”

Frequently Asked Questions

What is dependency risk in software?

Dependency risk is the chance that a third-party package your product relies on causes harm, through a bug, an abandoned project or a malicious release. The LiteLLM case on Oct. 21, 2026 was the malicious-release kind: Aikido Security found injected code in the PyPI wheels and Docker image of version 1.107.0.

Which LiteLLM version was compromised?

Aikido Security reported that LiteLLM 1.107.0 was compromised on PyPI and that the official Docker image for the same version was also affected. Per the GitHub issue that tracked it, the file landed on PyPI between 11:39 and 11:40 UTC on Oct. 21 and was pulled by 13:23 UTC.

What should I rotate if we installed LiteLLM 1.107.0?

Aikido says the payload went after cloud credentials, configuration for AI coding tools, and the LiteLLM database table where the proxy keeps API keys for each provider. Treat all of those as exposed and replace them with each issuing provider. Fireworks AI warns that deleting a stored secret does not by itself kill the credential behind it.

Is LiteLLM an npm package?

No. It is written in Python, and the compromised 1.107.0 release was distributed through PyPI and as a Docker image, according to Aikido Security.

How can a startup limit damage from a leaked AI API key?

Put a spending cap on every key and rotate on a schedule. OpenRouter recommends a credit limit on every key, warning that an unlimited key lets a leak drain the whole balance, and Anthropic suggests rotating keys on a consistent schedule such as every 90 days.

Sources

This article is general information for founders, not legal or security-consulting advice. Incident details are as reported by the sources cited on the dates shown and can change; for breach-notification duties, talk to counsel.