LiteLLM 1.107.0 Compromised: What LiteLLM Is, What Happened, and How to Protect Yourself

On October 21, 2026, attackers hijacked LiteLLM's release pipeline and published a malicious version 1.107.0 to PyPI and Docker. For about two to three hours, anyone who installed or pulled the latest LiteLLM got a credential stealer and a remote code loader along with it.

LiteLLM isn't a household name, but it sits underneath a lot of AI tooling. If your team builds anything with large language models, there's a real chance it's somewhere in your stack, possibly without anyone choosing it directly.

The short version

LiteLLM, explained for those in the back

Every AI provider has its own API. OpenAI, Anthropic, Google, AWS Bedrock, Azure, Mistral, and local tools like Ollama all expect slightly different requests and return slightly different responses. If your app needs to use more than one, that gets messy fast.

LiteLLM fixes that. It's a popular open-source project that comes in two forms:

1. A Python library. Your code calls one function in one format, and LiteLLM translates it for whichever of more than a hundred providers you've picked. Switching from one model to another can be a one-line change.
2. A proxy server, often called an AI gateway. Teams run it as a central service. Every app and developer sends AI requests to the gateway instead of straight to the providers. The gateway handles the provider API keys, tracks spending per team, enforces rate limits and budgets, logs requests, and hands out its own "virtual keys" to users.

Think of it as a switchboard between your company and every AI provider it uses. That's what makes it so useful, and also what makes it such a valuable target:

• It holds the master keys. A LiteLLM gateway typically stores API keys for every AI provider the company pays for, and often cloud credentials too.
• It sees everything. Prompts, responses, and logs flow through it, and logs can end up containing secrets.
• It's everywhere, sometimes invisibly. Many AI agent frameworks and developer tools depend on the LiteLLM library. You can have it installed without ever typing its name.

What happened on October 21

The project's real source code wasn't changed. Instead, the attacker took control of the release process and fed it a different source.

How the attacker got in

Accounts differ on the very first step, and investigations are ongoing. What's been reported so far:

• An exposed internal gateway. The attacker reportedly reached an internet-facing internal LiteLLM deployment. One report says a configuration file pushed to a public repository months earlier contained a master key for it. Another says the attacker pulled developer access tokens out of the deployment's logs. One vendor suggested an AI coding tool's output put tokens into those logs. That hasn't been confirmed.
• Stolen developer tokens. With tokens belonging to LiteLLM engineers, the attacker could act as them on GitHub. Reports say activity inside the project's repositories began about 11 days before the malicious release.
• Relaxed release controls. LiteLLM has said two engineers' tokens were used to trigger and approve the release, after release permissions had been temporarily loosened.

The lookalike repository trick

The release workflow was pointed at a lookalike repository whose name differed from the real one by a single hyphen (Berri-AI/litellm instead of BerriAI/litellm). That copy carried extra commits that added the malicious code. The official pipeline then built, signed, and published it as if it were a normal release.

That detail matters. Signature checks would have passed, because the signature only proves the official pipeline produced the package. It doesn't prove what source code the pipeline was fed. The build provenance record did show the difference: it named the hyphenated repository instead of the real one.

What the malware does (high level)

The malicious wheels add files to Python's site-packages folder that Python runs automatically every time it starts, whether or not your code ever imports LiteLLM. Reported files are cook.pth, cook.py, and sitecustomize.py.

Once running, it reportedly:

• Collects credentials: cloud provider keys, AI provider API keys, private keys, browser data, and authentication files for AI developer tools
• Sends them to the attacker
• Checks in about once an hour to download and run more code, so the attacker can do more than steal data

Because it runs at Python startup, simply having 1.107.0 installed in an environment was enough. And uninstalling the package afterwards doesn't undo anything that already ran or bring back stolen keys.

The response

LiteLLM pulled the release from PyPI and repointed the affected Docker tags within hours, locked down its registries, removed most members from its GitHub organization, and started revoking credentials. The lookalike repository is gone.

Not the first time this year

LiteLLM has had a rough 2026, which is worth knowing if you're deciding how much to trust any single dependency:

• March 2026: a separate supply chain attack published backdoored versions 1.82.7 and 1.82.8. That time, PyPI publishing credentials were stolen through a compromised security scanner used in LiteLLM's build pipeline, as part of a wider campaign that hit other packages too.
• Proxy vulnerabilities: several serious bugs were found in the LiteLLM proxy this year. They include a critical pre-authentication SQL injection (CVE-2026-42208, fixed in 1.83.7) that was exploited within days of disclosure, an authentication bypass (CVE-2026-49468, fixed in 1.84.0), and a flaw that could leak stored provider keys to authenticated users (CVE-2026-84377, fixed in 1.88.6 and 1.96.2).

If you run an old LiteLLM proxy, the safe version above also fixes all of those.

Am I affected?

You're likely affected if any of these happened on October 21, 2026:

• You installed or upgraded litellm with pip, uv, or Poetry without pinning a version, or a tool pulled in the latest version as a dependency
• You pulled a LiteLLM Docker image by the latest, main-latest, main-stable, or v1.107.0 tag
• Your CI pipelines rebuilt images or environments during the window
• A registry mirror or pull-through cache synced one of those tags. Mirrors can keep serving the bad image even after LiteLLM fixed its own tags.

How to check:

1. Check the installed version in every Python environment, including CI runners and containers. In each environment, run:

pip show litellm

2. Look for the planted files. Search each environment's site-packages folder for cook.pth, cook.py, or an unexpected sitecustomize.py. Finding any of them means the environment ran the malicious code.
3. Check transitive installs. Search your lockfiles (requirements.txt, poetry.lock, uv.lock) for litellm, even in projects that never use it directly.
4. Check your images. Review which LiteLLM image digests your clusters and hosts pulled on October 21, and what your mirrors cached.
5. Check your build logs for installs of 1.107.0 during the window.

What to do if you were affected

Treat every machine, container, or CI runner that ran 1.107.0 as compromised. Removing the package isn't enough.

1. Isolate the affected hosts and containers, and stop any running LiteLLM processes from the bad version.
2. Rotate every secret the machine could reach, from a clean device. That means AI provider API keys, cloud credentials, LiteLLM master and virtual keys, database passwords, GitHub and CI tokens, SSH keys, and anything stored in environment variables or config files. Assume all of it was stolen.
3. Rebuild, don't clean. Recreate virtual environments and images from scratch on litellm==1.106.2 (or a later confirmed-clean release). For containers, pin by digest, not by tag.
4. Clear caches and mirrors that may still hold 1.107.0.
5. Check for misuse of the exposed credentials: unusual AI usage and spend, new cloud resources or users, unexpected GitHub activity, and access from unfamiliar locations.
6. Report it internally under your incident response process, and tell your AI and cloud providers if you see their keys being abused.

How to protect yourself going forward

This incident is a textbook example of modern supply chain risk. These habits would have stopped or limited the damage, and they apply to every dependency, not just LiteLLM.

Pin and verify what you install

• Pin exact versions and use lockfiles with hashes, so a new release can't slip in automatically.
• Pin container images by digest. Tags like latest can be repointed at any time. Digests can't.
• Wait before adopting new releases. Many package managers and dependency bots can enforce a "cooldown" so you only adopt versions that have been public for a few days. Most malicious releases are caught within hours.
• Check provenance, not just signatures. Confirm that a build came from the expected source repository. A valid signature on the wrong source is still the wrong code.

Treat your AI gateway like critical infrastructure

• Keep the admin interface off the internet. Put the LiteLLM proxy behind a VPN, private network, or authenticating reverse proxy.
• Protect the master key like a root password. Store it in a secrets manager, never in a config file in a repository, and rotate it regularly.
• Scrub logs. Configure request logging so it doesn't store secrets, tokens, or sensitive prompts, and restrict who can read the logs.
• Use least privilege. Give each team or app its own virtual key with a budget and only the models it needs.
• Stay patched on the proxy itself. The 2026 CVEs above show the gateway is a target in its own right.

Lock down your own pipeline

• Turn on secret scanning for every repository, public and private, so leaked keys get caught before an attacker finds them.
• Use short-lived credentials in CI instead of long-lived tokens.
• Keep release controls strict. Require separate human approvals for releases, and don't relax them "temporarily."
• Pin CI actions and tools by commit, since a compromised build tool was the way in for LiteLLM's March incident.

Limit what a stolen key can do

• Set spending caps and usage alerts with every AI provider.
• Separate environments so a developer laptop or CI runner doesn't hold production keys.
• Keep an inventory of where your AI keys live, so you can rotate them all quickly when something like this happens.

Why this one matters

AI gateways concentrate a company's most valuable AI credentials in one place, and AI tooling moves fast, with frequent releases that teams install without much scrutiny. That combination makes projects like LiteLLM attractive targets, and this year shows attackers have noticed.

The lesson isn't "stop using LiteLLM." It's that anything holding the keys to your AI stack deserves the same care as your identity provider or your password manager: pinned, verified, isolated, monitored, and quick to rotate.

Sources

This write-up was compiled from LiteLLM's own advisory and security research published October 21–24, 2026. Where sources disagree, we've said so. Threat actor names that appear in some sources have been left out on purpose.

• LiteLLM: Oct 21, 2026 release v1.107.0 compromised (official advisory)
• LiteLLM GitHub issue #47826: 1.107.0 compromised
• StepSecurity: litellm 1.107.0 compromised on PyPI
• Socket: LiteLLM PyPI package and Docker images compromised
• Datadog Security Labs: LiteLLM supply chain compromise
• Wiz: LiteLLM compromised, steals credentials
• The Hacker News: Leaked LiteLLM master key let attackers hijack release pipeline
• GBHackers: Repository breached 11 days before the attack
• Snyk: How a poisoned security scanner became the key to backdooring LiteLLM (March 2026)
• NVD: CVE-2026-42208

This is a developing story. We'll update this page as LiteLLM and investigators publish more.