---
title: What to Do If You Installed the Compromised LiteLLM Release
url: "https://goremy.ai/blog/articles/litellm-compromised-release-rotate-ai-api-keys"
author: Luis Chavez-Mattos
editor: Luis Chavez-Mattos
editor_title: Director, Product
published: "2026-10-27T12:20:07.193Z"
updated: "2026-10-27T12:20:07.193Z"
topic: Cyberattacks & Patch Alerts
description: "LiteLLM's October disclosure describes a release with credential-stealing malware. How to investigate, contain, rotate AI provider keys and check billing."
---

# What to Do If You Installed the Compromised LiteLLM Release

> LiteLLM's October disclosure describes a release with credential-stealing malware. How to investigate, contain, rotate AI provider keys and check billing.

Edited by Luis Chavez-Mattos, Director, Product · Published 2026-10-27

## What should you do if you installed the compromised LiteLLM release?

Treat the environment that ran it as compromised. LiteLLM's October disclosure describes a distributed release that contained credential-stealing malware. The immediate advice is to follow the project's containment instructions, rotate every secret the affected system could read, and assume the access has already been used. Then check provider billing and usage logs for activity you did not cause. Upgrading the package is not enough, because it does not undo what already left the machine.

## TL;DR

- LiteLLM's October disclosure says a **distributed release contained credential-stealing malware**, and the project had already dealt with a separate compromise in March.
- A **clean source tag proves nothing** about the package your build job actually installed. The disclosure says the official tag was clean while the released files were malicious.
- **Rotate first, investigate in parallel.** Anything the gateway process could read should be treated as exposed, starting with model provider keys.
- **Revoke the old keys**, do not just issue new ones. A stolen key keeps working until you kill it.
- **Check billing and usage dashboards** for every provider. Stolen AI keys are spendable, and the victim gets the bill.
- Afterward, **scope keys per application and set spend caps** so the next incident costs less.

## What did LiteLLM actually disclose?

LiteLLM is a widely used tool that connects applications to AI models. Many teams run it as a gateway: apps send requests to it, and it holds the keys for the model providers behind it. That makes it a dense target. One compromised gateway can hold keys for several providers at once.

According to a security commentator's recap of the incident, the October disclosure describes a release that contained credential-stealing malware. The project had also dealt with a compromise in March. The guidance for anyone who installed the affected release was consistent: treat your environment as compromised, follow the containment instructions, and rotate secrets.

I am relying on that summary for the shape of the incident. For affected version numbers, indicators of compromise and the exact containment steps, read LiteLLM's own disclosure. This article does not restate details it cannot verify.

## Why doesn't a clean source tag prove the installed package was clean?

Because the thing you audit and the thing you run are different artifacts. Source code lives in a repository. What lands on your server comes from a build, then a published package, then your installer. Malicious files can enter at the build or distribution step without a single change to the tagged source.

That is the key detail in this disclosure: the official source tag was clean, while the distributed release contained malicious files.

Picture a common setup. Your customer app sends requests through a gateway built on LiteLLM. The gateway holds keys to several model providers. Automated jobs build and deploy it, and other internal apps use the same gateway. After the disclosure, you open the repository and the code looks fine. You check the running gateway and someone has already upgraded it. It is tempting to call the problem solved.

It is not solved, for three reasons:

1. Reading the source repo tells you nothing about what the package contained when your machine installed it.
2. The upgrade removed the bad version going forward. It did not remove whatever the bad version already read or sent.
3. The build job may have pulled the bad release too. Any secrets available to that job are in scope, not just the ones on the gateway host.

So the question to answer is not "is the code clean?" It is "which systems installed the affected release, and what could each one read while it ran?"

## How do you contain a compromised LiteLLM install?

Work through this in order. Speed matters more than completeness at the start.

1. **Identify every place the affected release was installed.** Check production gateways, staging, developer laptops, containers, and CI/CD runners. Use lockfiles, image layers, and build logs rather than memory.
2. **Isolate affected hosts.** Cut outbound network access where you can, so anything still running cannot send more data out. Preserve disks, images, and logs before you destroy anything.
3. **Stop the affected process and rebuild from a known-good state.** Do not patch in place on a host you now distrust.
4. **Follow the project's own containment instructions** for indicators and cleanup.
5. **Start key rotation immediately**, in parallel with forensics. Do not wait for proof of theft.

## How do you rotate AI API keys after an exposure?

Start with a list of everything the affected process or job could read. That usually means more than the obvious provider keys.

| Secret | Why it is in scope | Action |
|---|---|---|
| Model provider API keys (OpenAI, Anthropic, others) | The gateway holds them to make calls | Revoke, then issue new keys |
| Gateway master or virtual keys | Issued to your apps and users | Invalidate and reissue |
| Environment variables on the host or runner | Malware that reads the process environment sees them | Rotate everything present |
| Config files and `.env` files | Often contain keys in plain text | Rotate and move to a secrets manager |
| Database credentials the gateway uses | Needed for logging and key storage | Rotate |
| CI/CD secrets available to the build job | The build may have installed the bad release | Rotate and review pipeline access |
| Cloud credentials on the same host | Reachable from the same machine | Rotate and review access logs |

A few rules make rotation actually work:

- **Revoke the old key.** Creating a new key while the old one stays live protects nothing.
- **Rotate from a clean machine.** If you issue new keys from a host that is still compromised, you hand them to the attacker.
- **Deploy new keys only to rebuilt, verified systems.**
- **Update downstream consumers** so you do not trade a security incident for an outage. Other apps sharing the gateway will break when old keys die.

## How do you check for misuse and unexpected AI bills?

Stolen model keys are spendable. Someone can run workloads on your account, resell access, or both, and you pay. Tokens increasingly behave like cash, and the checks should look like a financial audit.

For each provider whose key touched the affected system:

- Review the usage and billing dashboard for spikes, especially in the window between the install date and your rotation.
- Look for models you never use, unfamiliar regions, odd hours, or traffic from IPs that are not yours.
- Check for newly created keys, projects, or members that you did not add.
- Export logs now, since retention windows can be short.
- Set or lower spend limits and alerts on the new keys.
- If you see charges you cannot explain, contact the provider's support with timestamps and key identifiers.

Do the same for cloud accounts. Credentials found on a gateway host can lead well beyond AI services.

## How do you reduce the blast radius next time?

Some of this is routine supply chain hygiene, and none of it is specific to one project.

- **Pin dependencies and verify hashes** in lockfiles, so a changed artifact fails the build instead of installing quietly.
- **Delay upgrades on critical infrastructure** by a short window, and watch security advisories before pulling new releases into production.
- **Give each application its own scoped key.** One leaked key should expose one app, not the whole company.
- **Cap spend per key and per project** at the provider.
- **Restrict outbound traffic** from gateway hosts to the provider endpoints they actually need.
- **Keep secrets out of build jobs** unless the job truly needs them, and use short-lived credentials where the provider supports them.
- **Review connected apps** on important accounts and remove access you do not use.

## Frequently Asked Questions

### Is upgrading LiteLLM enough to fix the problem?

No. Upgrading removes the bad version from your system, but any credentials it already read may have been sent out. You still need to rotate secrets, rebuild affected hosts, and check usage for abuse.

### If the source code on GitHub looks clean, am I safe?

Not necessarily. The disclosure says the official source tag was clean while the distributed release contained malicious files. What matters is the package your system installed, so check lockfiles, image layers, and build logs for what was actually pulled.

### Which keys should I rotate first?

Start with model provider keys held by the gateway, since they are directly spendable. Then rotate gateway keys, environment secrets, database credentials, and anything available to the CI/CD job that built or deployed the release.

### How do I know if someone used my keys?

Check each provider's usage and billing dashboard for unexplained spikes, unfamiliar models, and unusual traffic sources. Also look for new keys or members you did not create. Absence of obvious abuse does not mean the keys were safe, so rotate regardless.

### Where do I find the official indicators and affected versions?

In LiteLLM's own security disclosure. Use it for exact versions, indicators of compromise, and cleanup steps, and treat third-party summaries as context only.