Railway says stolen AI keys led to about $740,000 in unauthorised charges

At 07:28 UTC on 20 October, an attacker found a previously unknown flaw in Railway’s build system and slipped partway out of the isolation around a build. By the next morning they had decrypted a subset of customer environment variables. In a 10 November report, Railway said the stolen AI keys were later used for an estimated $740,000 in unauthorised charges — and that it will cover those costs when an AI provider will not.

Railway builds and runs apps for its customers and stores their secrets, such as API keys and database credentials, as environment variables. The company said the attacker could have decrypted variables in at most 1.85% of workspaces, about 100,000 — an upper bound, because the logs identify environments, not individual variables. Railway emailed customers it judged to be at high risk.

How the stolen AI keys were taken

The first foothold was a partial escape from filesystem isolation on a shared build machine. That let the attacker steal a credential that build servers used to push finished images and reach some internal systems. An on-call engineer was paged at 13:58 UTC, six and a half hours later, when unusual calls hit a registry service.

The credential was meant only for build work. Railway’s internal Temporal system, which schedules parts of the build process, also accepted it as a trusted client. Through it, the attacker read stored histories of 353 other builds, including their variables, and retrieved a copy of Railway’s own monorepo. The company says it has no indication that customer code was downloaded.

With that map of the platform, the attacker found a misconfigured OIDC binding — a setting that lets the deployment system request short-lived cloud credentials — and obtained one at 03:26 UTC on 21 October. That led to an orchestration machine, then to encrypted customer variables. Database logs show queries aimed at names that looked like AI provider keys, and one query also matched cloud, database and payment credentials. Railway says forensics did not show that customer databases were accessed.

The attacker was fully removed at 09:24 UTC on 21 October (2:24 PM Pakistan time). Railway halted builds twice, invalidated every user session and token later that day, and restored builds for all plans by 22:49 UTC on 22 October after moving each build onto its own short-lived virtual machine. The decrypted data also included linked-account tokens for 1,852 users, all of which Railway says it reset, with no account logins found. The Hacker News notes that a 26 October update had said Railway could not refund unauthorised AI spend; the 10 November report changes that offer and lists where Railway would cover the cost itself.

What’s confirmed versus unknown

Confirmed by Railway’s 10 November report (last updated 18:02 UTC that day): the timeline above; the 1.85% / about 100,000 upper bound; the estimated $740,000 in unauthorised spend; the 353 build histories; the 1,852 reset tokens; and the offer to backstop refunds.

Also confirmed as Railway’s assessment, not as an independent Amniat finding: the company believes the keys were destined for “distributed transfer stations” for model distillation.

Unknown or not yet stated in the sources: the attacker has not been named, and The Hacker News notes that the report does not say how the $740,000 figure was estimated or which dates it covers. Public indicators of compromise had not yet been released.

Three things to do today

1. Revoke and re-issue any AI, cloud, GitHub, or payment keys stored as environment variables on a host you do not fully control — starting with Railway if you use it, then any other shared platform.
2. Check billing dashboards for OpenAI, Anthropic, Google, AWS, and any reseller for charges you did not make, and file the provider’s and Railway’s report forms if you see them.
3. Turn off public network access to databases you do not need online, and review GitHub audit logs and connected apps, as Railway advised.

A next step

If a key or account may have been exposed, start with our free guide on what to do after a breach. It covers the same-day habits: rotate what was stored, turn on two-factor authentication, and watch for follow-on messages that piggyback on the news.