KeyRelay: The Life of a Stolen LiteLLM Key

LiteLLM is an open-source gateway that many organizations use to route their AI traffic. Attackers went after it hard in 2026. A SQL injection flaw that needs no login was exploited within about 36 hours of being disclosed. A command-injection flaw, CVE-2026-42271, was added to CISA’s list of known exploited vulnerabilities. The project was also hit by two supply-chain attacks, in March and October, and the first may have exposed more than 2,500 organizations. A gateway holds the keys to every AI provider behind it, so a stolen gateway key can spend all of that access.

To learn what happens after a key is stolen, we followed keys handed out by exposed LiteLLM gateways:

• Division of labor: Stolen keys operate on a relay model. On October 1, one source created six keys and left without using them. Over the next five days, five other sources in four countries used those same keys.
• Rapid handoff: Of 15 keys observed in use, 9 were presented from a source address other than the one that minted them. The fastest handoff to a new source took 26 minutes.
• Pre-use validation: Adversaries systematically validate keys. Sources using these keys sent 84 chat requests built from just 10 distinct prompts, repeated by script: liveness, instruction-following and tool-calling checks.

The KeyRelay pattern#

Following a key#

In traditional credential theft, the initial access broker rarely commits the ultimate fraud; credentials are harvested in bulk and passed to separate actors. We observed the same split around AI gateway API keys: the source that minted a key was usually not the one that used it.

Figure 1: Like identity theft and identity fraud, the source that mints a key is usually not the one that uses it.

Exposed LiteLLM gateways configured with sk-1234, the example master key from LiteLLM’s quickstart docs, issue a unique virtual key to anyone who sends it to /key/generate. Because each key is unique, its later appearances map the lifecycle of a leaked credential across the public internet.

Handoff case studies#

1. The October fan-out (slow relay)#

On October 1, a single source on Microsoft Azure queried /key/generate across six gateway hosts within 5.5 minutes, acquired six keys, and immediately disconnected.

Nineteen hours later, the first key reappeared from a consumer ISP in another country. Over the next five days, four more sources presented keys from the same batch. Each key was presented only to the host that had issued it, and one recipient presented five of the keys in the exact order they were minted.

“The source that mints a key is often not the one that uses it.”

Oct 1, 00:24 UTC  [Source: Azure cloud, Netherlands]  ──► Mints 6 keys via sk-1234
Oct 1, 19:47 UTC  [Recipient 1: ISP, Russia]          ──► Presents 5 of the 6 keys (GET /v1/models)
Oct 2, 05:38 UTC  [Recipient 2: Proxy, Japan]         ──► Presents all 6 keys (GET /v1/models + chat)
Oct 2, 08:08 UTC  [Recipient 3: Proxy, Slovakia]      ──► Presents 4 of the 6 keys (GET /v1/models)
Oct 6, 11:07 UTC  [Recipient 4: ISP, Russia]          ──► Presents 5 of the 6 keys, in minting order (POST /v1/chat/completions)
Oct 6, 11:48 UTC  [Recipient 5: Proxy, Romania]       ──► Presents all 6 keys (GET /v1/models + POST /v1/chat/completions)

Figure 2: The October KeyRelay lifecycle: one initial source minted six keys; five other source addresses in different countries presented them over a five-day window.

2. The August turnaround (fast relay: 26 minutes)#

A faster handoff occurred in late August. An initial source on Microsoft Azure minted three keys and executed minimal queries. About 26 minutes after the last key was minted, a second source on Oracle Cloud, which was running distinct client tooling, headers, and HTTP fingerprints, presented all three keys.

This Oracle Cloud hosted infrastructure matched scanning signatures previously identified probing for default sk-1234 keys, a small, concrete thread tying the hunt for exposed gateways to the reuse of what comes out of them.

3. File harvesting vs. direct minting#

To compare key-minting against passive credential harvesting, we also followed an OpenAI-format key (sk-proj-…) found in exposed .env files.

• Direct scanning: Hundreds of unique sources retrieved the .env file, but the vast majority never executed requests.
• Staged pipelines: Two separate sources read the file and went quiet for 20 hours and 2 hours respectively, before executing identical six-request validation bursts across varying header configurations (Authorization: Bearer vs. x-api-key).
• Secondary handoff: A third source submitted the same key to /v1/models without ever accessing the .env endpoint, so it most likely reached this source from one that did read the file.

Probing and validation behaviors#

Sources that presented a minted key sent 84 chat completion requests in all, including some made with sk-1234. Only 10 were distinct prompts; the other 74 repeated one of them, representing scripted capability validation rather than production workloads.

Prompt breakdown#

Table 1: Distribution of the 84 observed validation prompts across distinct capability checks.

Requests frequently asked for budget models (specifically DeepSeek variants) not advertised by the gateway’s routing table, showing that testing scripts arrived with predetermined target lists. All 84 were functional checks. Sources that minted keys for their own use went further: one tried to extract the model’s system prompt five minutes after minting a key, and another used a key it had minted nine minutes earlier to authenticate a remote-code-execution request through LiteLLM’s MCP connection test, harvesting the gateway’s environment variables and config files.

Observed request timelines#

Minting, handoff and probing sequence (October)#

Table 2: One source minted six keys; five other sources presented them over the next five days, most of them also trying sk-1234.

Environmental secret harvesting and validation sequence (September)#

Table 3: Two sources replayed an OpenAI-format key 20 and 2 hours after reading it from exposed .env files; a third used it without a prior read.

August (direct mint):   [Issuance]  ──(26 min)──►    [Secondary reuse]
.env file harvest:      [File read] ──(2h to 20h)──► [Scripted replay]
October (relay mint):   [Issuance]  ──(19h)──►       [First probe] ──► [Active reuse to day 5]

Figure 3: Observed timelines across access methods. Minted credentials showed reuse windows between 26 minutes and 19+ hours, while harvested .env secrets showed multi-hour validation latencies.

Defensive recommendations for LiteLLM deployments#

1. Assume leaked keys are distributed immediately. A compromised credential can propagate to external infrastructure in under 30 minutes. Invalidate and rotate exposed keys immediately upon suspicion.
2. Replace the example master key. sk-1234 is the placeholder from LiteLLM’s quickstart and should not be kept as the default. Also apply all vendor patches for disclosed CVEs.
3. Monitor /key/generate calls. Alert on key generation requests from unexpected source addresses. If admin credentials are exposed, rotating the master key does not invalidate previously issued virtual keys; these must be revoked explicitly.
4. Correlate runtime event chains. Do not depend solely on single-request anomalies. The high-fidelity indicator is the behavioral progression: unexpected key minting → connection from a novel IP pool → structured liveness/tool validation sweeps.
5. Protect flat-file secrets. Ensure runtime configurations and .env files are excluded from public routing roots.

Detection engineering: catching the sequence#

Static indicators (IP addresses, autonomous system numbers, user-agent headers) rotate across each phase of this lifecycle. Furthermore, unauthorized virtual keys pass normal gateway authentication routines.

Defenders must connect state across events: linking an unexpected key issuance to subsequent model-probing behavior from unfamiliar networks. When credential sharing cycles occur in 26 minutes, security teams cannot rely on post-incident log reviews; detection must occur at runtime as the chain unfolds.