Stolen AI API keys: what the Railway breach teaches us

Short read

This post covers the Railway breach, where attackers broke out of a build server, moved through the platform and decrypted customers' stored secrets to hunt for AI API keys. Railway now estimates about $740,000 in unauthorised AI usage from the stolen keys.

You'll learn how the attack unfolded, why stolen AI API keys have become such a popular target, and the practical steps to protect your own keys, wherever your apps run.

Stolen AI API keys have quickly become one of the most valuable things an attacker can take from a cloud platform, and the Railway breach shows why. Railway, a platform-as-a-service provider that builds and runs apps for its customers, said this week that AI provider keys stolen from customer environments in an October breach have led to an estimated $740,000 in unauthorised usage charges, according to The Hacker News. The company has promised to cover those charges itself where an AI provider won't refund them.

If your developers keep API keys in environment variables on any hosting platform, and most do, this incident is worth understanding.

What happened in the Railway breach

Railway's full incident report sets out a chain of steps, none of which would have been enough on its own:

• A build escape. At 07:28 UTC on 20 October, the attacker exploited a previously unknown flaw to partly escape the filesystem isolation around a build and read files on the host machine. That gave them a credential that build servers use to push finished images.
• Too much trust in one credential. That credential was meant only for build work, but an internal system that drives the build process accepted it as a trusted client. The attacker used it to read the stored histories of 353 builds, including the secrets passed to them, and to fetch a copy of Railway's internal source code.
• A cloud misconfiguration. By reading that code, the attacker found a wrongly configured OpenID Connect (OIDC) binding, part of how the deployment system gets short-lived cloud credentials. At 03:26 UTC on 21 October they used it to obtain a cloud credential, and from there an SSH key.
• Reaching the keys. The SSH key opened an orchestration machine that held a credential able to decrypt customer variables. Database logs show the attacker searching specifically for variable names that matched AI provider keys, and targeting customers with large numbers of variables.

Railway says the attacker could have decrypted variables in at most 1.85% of workspaces, about 100,000, and stresses that this is an upper limit because its logs show which environments were exposed, not which variables. Linked-account tokens for 1,852 users, including GitHub OAuth tokens, were also exposed and have been reset. The attacker was fully removed at 09:24 UTC on 21 October.

One detail stands out for anyone running a security team. According to The Hacker News, the on-call engineer was paged at 13:58 UTC on 20 October, when an alert flagged unusual calls to a registry service, about six and a half hours after the first exploit.

Why attackers want AI API keys

AI provider keys are attractive for a simple reason: they turn straight into money. A stolen key can be used to run large volumes of AI requests that someone else pays for. Railway believes the stolen keys were used by services that relay or resell access to AI providers for use in distillation, although it hasn't established whether the attacker ran those services.

Railway isn't alone. The Hacker News reports that Wiz researchers list this breach among incidents disclosed in October by at least nine AI developer platforms, and that every public report describes attackers hunting for stored environment variables, especially ones that grant AI access. No single flaw or software dependency links them.

The cost also lands unevenly. As BleepingComputer and The Hacker News describe, refund terms vary from provider to provider, from fraud refunds already under way to case-by-case reviews and, in one case, a no-refund policy. In Railway's case the platform has stepped in, but you can't count on that next time.

What to do if you used Railway

Railway's advice, summarised from its incident report and The Hacker News:

• Revoke and replace any sensitive variable stored on the platform before 21 October. Do this with the provider that issued each key. Filing a charge report with Railway does not revoke a key.
• Remove public network access to databases where you can.
• Check your GitHub audit logs and review which apps can access your account.
• Check audit logs in container registries such as Docker Hub.
• Report charges you didn't make using Railway's charge report form, and raise claims with the AI provider as well.

Railway notes that a revocation notice from a provider doesn't by itself mean your key was exposed, because it handed over every key it held as a precaution.

Protecting AI API keys wherever your apps run

Even if you've never used Railway, the same weaknesses exist in many organisations. A few practical steps go a long way:

• Know where your keys are. Keep an inventory of AI, cloud and payment keys, who owns each one and where it's stored. You can't rotate what you can't find.
• Set spending limits and alerts with every AI provider. A sudden jump in usage is often the first sign a key has been stolen, and a hard cap limits the damage.
• Use separate keys per app and environment. If one leaks, you revoke one key rather than breaking everything.
• Rotate keys regularly, and immediately after any supplier tells you about a security incident.
• Give credentials the least access they need. The Railway attack moved forward because one build credential was trusted far beyond its purpose.
• Review your cloud trust settings. OIDC and other federated identity bindings should be checked for overly broad trust, just like passwords and keys.
• Watch for unusual activity, around the clock. The Railway attacker worked through the night. Unusual registry calls, new SSH sessions and bulk reads of secrets are the kinds of signals that need someone looking at them quickly, not the next morning.

The bigger lesson

The Railway breach wasn't one catastrophic bug. It was a build escape, a credential trusted too widely, a cloud misconfiguration and a machine holding the keys to decrypt everything, chained together over about a day. It was an alert about unusual registry calls that first brought it to the on-call engineer's attention.

That's why secrets management and detection belong together. Strong key hygiene limits what an attacker can take, and continuous monitoring shortens the time they have to take it. If you want to see how urgentic approaches that, the platform overview and products page are good places to start.