We leaked LLM gateway api keys for 35 days. Here's what happened.

Leak location and project type

Which leak locations drew requests

We compared the projects, the files containing the keys, and the time each key had been public. The table covers three batches of 40 repositories. To give each key the same observation period, we counted only its first 24 hours after release.

In the early batch, one source checked 37 keys within a minute of each release. These were model-list requests. The entire batch produced only seven prompt requests, all from another source repeating the same message. Broad collection did not lead to sustained use of every key it found.

The two utility batches let us hold several things constant. All 80 projects were Python tools, advertised gpt-6-sol, and contained a key beside the gateway URL in config/development.env. Yet only 17 keys were checked and five were used for prompts. The other 63 never appeared in our gateway logs during more than four days of observation.

The four New York utility keys used for prompts came from api-response-code-map, http-header-safety-check, pagination-field-check, and operation-id-audit. San Francisco’s came from cors-wildcard-credentials-check. They were all API-related tools. These projects differed in release order and organization, so we cannot tell whether their subject matter drove the selection.

File format may matter too. Six of the early batch’s seven prompt-tested keys came from Go projects with JSON configuration; one came from a Node project, and none from its 14 Python projects. All seven prompt requests came from one source. Language and file format changed together, so we cannot tell which affected that source’s choice.

We also tried other leak locations. A GitHub Gist key received eight prompt requests. Keys in two documentation pages and two downloadable starter archives received no gateway requests over roughly six days. One of six keys exposed in commit history was checked and used for prompt attempts. Those small groups show which surfaces produced observable use, but not which were scanned.

The newest keys had less time to be found: 19 had been public for less than a day. But 91 keys had at least three days of exposure without a request. All 64 keys whose first request we could time were checked within six hours of release. We did not retain repository crawl or download telemetry, so we cannot distinguish a key that was never collected from one that was collected and ignored.

Once a few keys were adopted, their repeated use dominated the traffic. Six keys accounted for 98.9% of prompt requests using our leaked credentials. Repeated use of these keys drove the request volume.

Requests with other credentials

The arithmetic question behind most captured prompts

A request can carry any string as its API key. We recorded those attempts even when authentication failed, so a saved prompt does not necessarily mean the sender had a working key. Many attackers tried to brute force over 100+ admin keys that didn't work. This relates to an original vulnerability with LiteLLM where many gateways shipped with a default admin key

What the repeated credential tests looked like

Prompt requests carried 93,100 nonempty credential values outside our publication records. Of those, 78,130 were only 1–16 characters long. 93.7% of prompt requests outside the publication match returned HTTP 401. Almost all of these attempts carried curl-labelled headers.

The clearest repeated pattern was this message:

What is 483*927+1145? Answer with only the final number.

We captured 1,401,673 copies across 92,596 supplied credential values and 20 requested model names. None of those values matched our documented leaks. Replaying a fixed question while changing the token and model is consistent with automated credential and model testing.

Repeated use of our leaked keys

A key check described how a relay collected API keys

This source made 1,215 prompt requests using our leaked keys. Within that traffic, we recorded 21 copies of one exact message. We’re highlighting it because it described how a relay collected and managed API keys. It began:

“The relay pool keeps a small SQLite database of API keys collected from public channels.”

The prompt described a “relay pool”: keys and API connections managed by a gateway. The system would retry keys that had hit their quota once an hour, test all the keys every six hours, and update the gateway’s routing each day. It would choose connections based on throughput, response time, and account balance, and could block collection sources by chat title.

After that description, the only instruction to the model was Ответь одним словом: OK—“Answer with one word: OK.” The requests also carried the software label keypool in their user-agent header.

Of those requests, 12 returned HTTP 200, 7 returned 429, and 2 returned 404.

This is the system described in the submitted prompt; we did not inspect the collector’s code.

Gateway connections

Following the traffic to an API relay

my.git.christmas resolved to an IP that was sending prompts to our API. Requests from that IP also mentioned the domain. Veridrop lists it as an OpenAI-compatible API relay.

Requests from the same IP referred to a fo2api deployment. Together, the DNS record and prompts linked the source to relay infrastructure, though they didn’t tell us how many users were behind it.

The older logs retain a forwarded source address, without a separate socket-peer record. The DNS and context matches support the link; they do not identify an operator.

Relay development and testing

Troubleshooting a relay through our gateway

The sender also used our gateway to troubleshoot fo2api. One prompt asked a coding agent to fix a production JSON tool-schema error affecting ChatCompletions, Responses, and Anthropic routes, and pointed it to specific backend files to inspect.

From a chat export into a gateway’s key pool

Earlier turns asked the agent to check keys from a chat export, find ones that could serve StepFun models, and add the working ones to a Sub2API-based gateway. NaraRouter’s endpoint appeared in the export and in the testing output. A generation probe returned 402, and a later account listing marked that connection as an error.

The user then supplied an OpenLux endpoint and key, asking the agent to check it and add it to the API. The following tool output included model tests, retries, and routing mappings. A later listing showed the OpenLux account as active.

An APIMart key came next, along with a request for auto-glm, auto-kimi, auto-qwen, and auto-stepfun: model names that would route requests between the best working models in each family. The APIMart test output reported 402 errors for insufficient balance, and its account was listed as an error.

A separate history from another IP included the CLIProxyAPI README. That task was to configure a coding agent to send service_tier: "fast" through the proxy. OpenLux and APIMart also appeared in the README’s sponsor list; those links were incidental to the documentation lookup.

These were instructions and tool results inside submitted histories, not calls from those providers to our gateway.

Telegram bot traffic

What Telegram histories revealed about the traffic

Telegram message metadata and earlier replies appeared in 88 captured requests from three recorded source addresses, including the source linked to my.git.christmas.

Another of those addresses was in Helsinki on Xorek-labelled hosting, in the AEZA network. It sent 31 of the captures containing Telegram conversation metadata. The submitted histories included 12 distinct sender IDs marked as non-bot accounts. This is the same source discussed in the hosting section; the location describes its server, not the people in the conversations.

The reply history highlighted telegram bot named @obed2021bot, with the same account ID across all three sources. In its public profile it is called “Обед” and advertises GPT 6 Astra Max along with free access to whomever has access. The message metadata from this bots requests also included two fields: guest_query_id and guest_bot_caller_user: Telegram fields for guest-mode bot interactions. Those fields give us enough evidence that we can say that Telegram conversations were being passed through an inference gateway to our system.

After removing duplicate message metadata, we found 29 distinct sender IDs marked as non-bot accounts. They appeared in 16 private chats and 10 supergroups. These are IDs in the conversation histories, not verified users. We have omitted personal identifiers.

{
  "format": "telegram_message_context/v1",
  "message": {
    "reply_to_message": {
      "from": {
        "is_bot": true,
        "username": "obed2021bot"
      }
    }
  }
}

We couldn’t verify who operated the bot or whether our replies reached Telegram.

Browser testing

Testing our leaked keys from a browser

6 requests using our published keys carried a www.hvoyai.com referrer. Each returned HTTP 200 and used the default message in Hvoy’s current tester:

“Calculate 17 + 26. Reply with only the number.”

The tester takes an endpoint, key, and model name, then sends the request directly from the visitor’s browser. The matching prompt and browser headers point to visitor-side testing, not a request from Hvoy’s servers. We checked the current implementation; we don’t have a historical copy.

Following the test requests

A browser test led back to VPN infrastructure

Other requests from the IP behind the Hvoy tests included instructions for maintaining updates.listokdoma.ru. When we checked DNS, that domain and related subdomains pointed to the same IP. This links the recorded address to the VPN configuration in the prompts; it doesn’t link Hvoy to the VPN.

Using our published keys, the same recorded address made 155 prompt requests; 132 returned HTTP success.

Asked to review a coding agent’s actions

Some prompts asked for a safety score for a coding-agent action, formatted as <severity>N</severity>. They included commands, browser output, project instructions, and configuration from the session being reviewed. The commands were review material, not instructions to execute on our gateway.

Hosting infrastructure

Where the leaked-key prompt traffic came from

Of the 9,375 prompt requests using our leaked keys, network lookups classified 8,058 (86%) as coming from hosting infrastructure. The largest groups included Xorek, Hetzner, and the PLAY2GO and Liteserver networks.

Requests using our leaked keys came from 53 recorded autonomous systems (ASNs)—network identifiers used for internet routing. Another 2 requests had no ASN. The table shows the eight largest groups; the complete breakdown is below.

Shares use all 9,375 leaked-key prompt requests. Activity counts describe captured inputs, include rejected requests, and can overlap. Software fingerprints are sender-supplied header labels.

HTTP 2xx counts successful request statuses. ASN holders, hosting brands, and the people using their services are separate identities.

European servers, Russian payment options

PLAY2GO and Xorek both advertise hosting accessible through Russian payment systems. Together, their recorded sources accounted for 4,950 requests (52.8%) using our leaked keys. That groups their payment offerings, not their ownership.

PLAY2GO lists ruble and euro prices, and its public channel advertises Russian cards and SBP payments. Its current website names a Dubai company, PLAY2GO - FZCO. The UK filing for PLAY2GO International, the name in our ASN records, lists a Ukrainian controlling shareholder.

Xorek offers Moscow and European server locations with ruble pricing and MIR/SBP payments. Its website identifies DpkgSoft International as the operator; that company’s UK filing lists a Russian resident with at least 75% ownership.

A sanctioned network behind the Telegram-linked traffic

One source connected from an address geolocated to Finland on the network of AEZA International, a U.S.-sanctioned hosting company. The Xorek-labelled traffic spans two ASNs: 2,208 requests on AEZA International’s AS210644 and 86 on DpkgSoft’s AS215590. Treasury describes it as the UK branch of Russia-based AEZA Group.

That is a documented connection to a sanctioned network. Our logs do not show who paid for these servers or establish sanctions evasion by PLAY2GO or Xorek.

Rostelecom’s AS12389 also appeared in the logs, with 12 leaked-key prompt requests, all returning HTTP success. Its OFAC listing carries narrower restrictions: Directive 3 prohibits U.S. persons from dealing in specified new debt with a maturity longer than 14 days or new equity. AEZA’s SDN designation is broader: its property under U.S. jurisdiction is blocked, and U.S. persons are generally prohibited from dealing with the company.

Half the prompt traffic came from two Finnish addresses

Two recorded addresses geolocated to Finland sent 4,749 requests—51% of the leaked-key prompt traffic. One was the address linked to my.git.christmas on the PLAY2GO network. The other was on Xorek-labelled hosting and also sent the Telegram conversation histories described above.

The larger Xorek source sent 2,208 requests under 23 model names. It mixed short checks with longer requests: 830 contained coding-agent system instructions. The network address therefore covered both automated checks and agent activity; its Finland location does not tell us where the users were.

The same check ran on Xorek and Hetzner

Two recorded addresses repeatedly sent Reply exactly: ok: 67 requests from Xorek-labelled hosting and 315 from Hetzner. All 382 carried a Zoltraak-labelled header, with one user message, no streaming, and a request for only five or eight output tokens.

The checks covered 11 model names and 6 leaked keys. The Hetzner address sent them to both honeypots. The matching prompt, header and request settings suggest shared checking software; they do not establish that the two addresses had the same operator.

Gateway capability tests

5,000 requests to find out what our gateway could do

A server geolocated to Buffalo, New York, on ColoCrossing hosting kept asking our gateway to edit a Python file, identify a cat, and find a marker buried in a long input. It repeated these tasks under different model names, checking what the endpoint could do.

Across 27 days with recorded traffic, it sent 5,036 prompt requests under 18 model names, plus 368 model-list checks. 3,254 prompt requests returned HTTP success.

The requests carried AutoGenX-Engine/9.1 headers. Their system instructions described an “internal routing and logging system” serving models “via OpenRouter.” We found that description in 172 captured requests. It describes the sender’s setup; it does not establish that OpenRouter sent the traffic.

There were only 183 distinct user messages in the captures. The repeated tasks explain much of the volume:

The coding test asked for a specific edit: change PORT from 8000 to 9090 and add TIMEOUT = 30. It supplied a Windows-style C:\work workspace and coding-agent instructions, then repeated the task under 17 model names. The histories contained no assistant or tool turns, so we could see the task being tested but not whether any resulting tool calls were executed.

Other tests checked images and long inputs. The roughly 77,000-character image payload was mostly an embedded JPEG. The retrieval tests hid a marker about 15% or 90% of the way through repeated filler text; the largest input contained 396,862 characters. In 283 requests, the sender asked for up to one million output tokens. That is a request setting, not measured consumption.

Another honeypot recorded the AutoGenX-Engine header family on model-API probes. Here, the repeated tasks show capability testing. We found no customer conversation histories, resale prices, or key-pool configuration in this source’s captures.

The recorded reverse-DNS name was sportsmanslocker.com, but forward DNS did not match the source address when checked. We have not identified the operator. Its credential did not match our publication records, so these counts are separate from the leaked-key totals.

Access checks

What happened after a key worked

The requests also showed how people tested the keys: trying different model names, repeating a check on a schedule, or using the same key from several addresses. In the examples below, we’ve replaced IPs with labels that apply only within each example. We estimated start times from completion timestamps and latency, including time spent waiting in the gateway.

Daily activity

How leaked-key use changed over time

We tracked the keys we leaked on GitHub to see how they were used. The chart shows all 11,841 requests using those keys: model-list checks, prompts, and failed attempts.