Railway Puts Charges on Stolen AI Keys at About $740,000. Its 100,000-Workspace Figure Is a Ceiling From October 22, and Its Indicators Stay Private for Now
If you stored an AI provider key in a Railway environment variable before October 21, revoke it at the provider today, even if you have already filed a charge report. Reporting a charge does not revoke a key. Railway now says the attacker who got into its platform on October 20 went after AI keys first, and that unauthorized spend on the stolen keys was estimated to reach about $740,000. This is LLMjacking, the theft of metered inference capacity: the attacker does not want your data, they want the model usage your key pays for.
We wrote about this on November 3, when neither Railway nor Trigger.dev had said how, and added a November 10 update to that post when Railway's incident report came out: Two Platforms That Run Your Code Disclosed Access to Customers' Environment Variables in Eleven Days. This post covers what that update did not: what the numbers mean, what the attacker queried for, and what Railway will and will not publish.
How it happened, per Railway
Railway's incident report, last updated November 10 at 18:02 UTC, gives the chain. All times are UTC.
- October 20, 06:50: the attacker starts probing Railway's build infrastructure.
- 07:28: a previously unknown flaw lets the attacker partly escape file isolation on a shared build machine and take a build credential. An internal workflow system accepted that credential as a trusted client. That exposed stored build histories and, through cache snapshots, a copy of Railway's internal code.
- 13:58: alerts on unusual registry calls page an engineer, six and a half hours after the escape. Builds are halted at 17:03.
- October 21, 03:26: a mistaken cloud identity binding gives the attacker a short-lived cloud credential. That leads to a machine holding a long-lived credential able to decrypt customer variables.
- 04:07 to 05:21: the attacker queries the encrypted variables database. Railway says it selected "rows where the variable name matched attacker-provided regular expressions," prioritizing AI provider keys, and that "an additional query also matched cloud, database and payment service credentials." Railway's logs also show the attacker "was specifically targeting customers with large numbers of variables in their environment."
- 04:42 to 05:14 and 06:36 to 07:15: variables are decrypted through the key management service.
- 07:14: Railway disables all active cloud credentials and the decryption service. The attacker is evicted at 09:24.
Railway's October 22 preliminary report dated the attack from 13:58 on October 20 and put decryption after 05:27 on October 21. The final report moves the start back six and a half hours and the first decryption 45 minutes earlier. If you searched your provider logs from the preliminary times, search again from October 20.
Railway says a team hardening the build system derived a second exploit within an hour of the first patch, which is why it moved every user to a new build system at once. Each build now runs in its own short-lived virtual machine.
The money
"Unauthorized spend on the stolen keys was estimated to reach ~$740,000." That is all Railway says. It does not say how the estimate was made, which providers it covers or what period it spans. The keys were customers' own, so the charges landed on customers' provider accounts. Railway believes the keys were "passed on to distributed transfer stations for use for distillation." In plain terms: resold to services that pool stolen keys to run models, here to generate training data. Railway says it has "not established whether the original attacker operated those services."
Who pays, per Railway as of November 10: AWS Bedrock and Google Gemini treat it as fraud and have started refunds. OpenAI reviews case by case; open a support case and give the case ID to Railway support. SpaceXSI also reviews case by case through Railway support. Anthropic is still in discussions, and Railway is covering those charges meanwhile. OpenRouter is enforcing its no-refund terms, so Railway is covering those charges. Report charges through Railway's form.
What "up to 100,000 workspaces" means
It is not a count of victims. Railway's wording is that "at most 1.85% of workspaces, about 100,000, could have had any of their environment variables decrypted." The population is all Railway workspaces. The figure is a ceiling, because Railway's logs identify environments, not individual variables. So a workspace in the 100,000 may have had nothing decrypted, and Railway cannot say which ones did. This is not new: the October 22 preliminary report already said "at most 1.85% of all workspaces," about 100,000. What is new is the dollar figure.
Three other populations are separate from it:
- 1,852 users had linked-account tokens exposed, meaning their own agent keys and GitHub OAuth tokens. All were reset, and Railway found no logins using stolen credentials.
- 353 builds had their stored histories read on October 20, including sealed variables.
- Every key Railway held, for GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google and Stripe, was sent to those providers as a hash "to isolate blast radius." A revocation notice from a provider therefore tells you your key was on Railway, not that it was taken.
Railway emailed the customers it judged at high risk. It says data the attacker copied but did not decrypt can no longer be decrypted, because the credential used has been disabled. It says forensics did not indicate customer databases were accessed, and it has no indication customer repositories were downloaded.
Indicators
None published. Railway says it is "sharing IOCs privately" with partners and will publish them once law enforcement signs off. It has filed a complaint with the FBI's IC3. The attacker is not named. Railway cites Wiz's "Black October" research on attacks against AI developer platforms as context, not as attribution. Until the indicators are out, the only way to find use of a stolen key is in your provider's logs, which is where the steps below send you.
What to do, in order
The first three are Railway's advice. The order is ours.
- AI provider keys. Revoke and replace them at the provider: OpenAI, Anthropic, Google, AWS Bedrock, OpenRouter and any others. Then check each provider's usage from October 20 onward for requests you did not make, and file what you find with the provider and on Railway's form. These keys were the target and cost money every hour they stay live.
- Payment and cloud credentials. Railway says a query matched them. Rotate Stripe keys and cloud access keys next, and check their audit logs for the same window.
- Database credentials. Rotate them, and remove public network access to the databases if you have not. Railway recommends both.
- GitHub and registries. Check the GitHub audit log and the apps authorized on your account, and the audit logs of registries such as Docker Hub.
- Everything else stored as a variable before October 21. Railway's own advice is to rotate all of it.
If your workspace had many variables, move it up the list. Railway says that is what the attacker selected for.
What is not known
How the $740,000 was estimated and whether it is still rising. Which workspaces inside the 100,000 actually had keys decrypted. The indicators, and who the attacker is. Whether Railway's incident is connected to the ones at Trigger.dev and at Northflank, which we covered on November 1, are connected. Nothing we read says so.
How we know, and how we checked
We read Railway's incident report and its October 22 preliminary report, then The Hacker News coverage. BleepingComputer reported the same $740,000 figure on November 10; we cite its report but did not re-read it for this post. Every number above is Railway's; we have no figures of our own. This was not visible to our edge instruments. The intrusion happened inside Railway's infrastructure, and the stolen keys were used against AI providers' APIs, not against anything we run. We add nothing to our feed: no indicators were published in the sources we read.
Sources
Railway, "Incident report: October security incident," last updated November 10, 2026, 18:02 UTC. Railway, "Preliminary report: October security incident," October 22, 2026. The Hacker News, "Railway says stolen customer AI keys..." (thehackernews.com/2026/11/railway-says-stolen-customer-ai-keys.html), November 2026. BleepingComputer, "Railway breach leads to $740,000 in fraudulent AI charges," November 10, 2026.
Five percent of this is wrong somewhere. It always is.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.