Could your API keys have been exposed?
In October 2026 three incidents involving customer secrets came to light: Railway's environment variables, LiteLLM release 1.107.0 shipping a credential stealer, and TiDB Cloud's encrypted API keys.
We inventory your secrets, rotate them in an order that cuts the biggest risk first, revoke the old ones, check whether anyone used them and move them into a secrets manager with short-lived tokens.
# Which LiteLLM version is installed?$ pip show litellm | grep -i ^versionVersion: 1.107.0# 1.107.0 is the malicious release published on 21 Oct to PyPI and Docker Hub$ docker images | grep -i litellm$ grep -rn "litellm" requirements*.txt pyproject.toml poetry.lock uv.lock 2>/dev/null# Pin the last good version in the lockfile and in your images$ pip install "litellm==1.106.2"# Pinning does not clean the machine: rotate every secret it could reachThree incidents, the same job left to do
In all three cases the provider has done its part, and rotating what was exposed falls to the customer: the provider cannot change your Stripe key or your OpenAI key.
Railway
On 21 October it detected anomalous activity in the systems that store customer environment variables. A third party may have accessed encrypted variables and in some cases decrypted them. It paused deployments and asks customers to rotate credentials. No count of affected customers or attack vector has been published. Source.
LiteLLM 1.107.0
On 21 October a malicious 1.107.0 was published to PyPI and Docker Hub: it steals credentials and loads remote code when any Python process starts. The attackers used GitHub CLI OAuth tokens stolen from three engineers; the GitHub tag is clean. It is the second time this year. Source: Wiz.
PingCAP / TiDB Cloud
Between 9 September and 7 October a third party used stolen service account credentials and copied account and project metadata, SQL editor text, billing records and encrypted API key values. No evidence of impact on data stored in TiDB. Source: PingCAP.
Six steps, from inventory to short-lived tokens
The first four cut off access and measure the damage. The last two change how you store secrets, so the next leak touches fewer things and lasts less.
- 01
Secrets inventory
PaaS variables, .env files, CI secrets, keys baked into Docker images and into the code. For each one: what it grants access to and how many places it lives.
- 02
Rotate in order
AI providers, cloud, databases, payment gateways and CI tokens. First whatever turns fastest into consumption or access to more secrets.
- 03
Revoke the old ones
A key you no longer use but is still active is just as useful to whoever has it. We check at each provider that the previous one is revoked.
- 04
Review usage logs
AI provider usage, CloudTrail or your cloud's audit log, database access and the Stripe dashboard, across the exposure window.
- 05
Secrets manager
We move secrets into a manager (your cloud's own, Vault or Doppler) so each one lives in one place and rotating means changing one value.
- 06
Short-lived tokens
Where the provider allows it, CI and services request temporary credentials (OIDC, IAM roles) instead of storing keys that never expire.
What gets rotated first, and why
LiteLLM is a proxy in front of model providers, so a machine running it usually has the AI keys at hand. With a stolen AI key someone can run up consumption on your account within minutes, and a cloud key opens up the rest.
CI tokens go at the end of the list because we use them to deploy the earlier changes. If there are signs that CI itself is compromised, they move to the top and we deploy from elsewhere in the meantime.
Create, deploy, revoke, verify
Revoke before the new key is deployed and the application goes down. Deploy the new one without revoking the old and the leak stays open.
Fewer places where each key lives
What takes longest in an emergency rotation is finding out where every key is. A secrets manager turns that inventory into something that already exists before the incident.
- The same API key lives on the PaaS, on two people's laptops and in CI
- Nobody knows how many places need touching to rotate it
- Keys never expire: one leaked a year ago still works
- No record of who read which secret, or when
- Each secret lives in one place (AWS Secrets Manager, Vault, Doppler or your cloud's own) and apps read it from there
- Rotating means changing one value and redeploying
- CI gets temporary credentials over OIDC instead of storing long-lived keys
- The manager logs access, and that is the first thing you check in an incident
Do you use Railway, LiteLLM or TiDB Cloud?
Write to us →FAQ about exposed credentials
We use Railway. Do we have to rotate everything?
We have LiteLLM 1.107.0. Is downgrading to 1.106.2 enough?
What should we do if we use TiDB Cloud?
Why that order?
Does rotating mean we are safe?
We start with the inventory
Tell us where you deploy and which providers you use. From that we prepare the list of secrets to rotate and the order, and you decide whether we run it or your team does.
Tell us your challenge. We'll propose a solution.
No commitment. Within 24 hours, you'll receive a proposal with scope, timeline and budget. No fine print.