Railway Breach Turns Stored AI Keys Into $740K in Fraud

Railway, a platform that builds and hosts applications for developers, said in an incident report dated November 10, 2026 that an intruder who got into its systems on October 20 and 21 decrypted stored customer secrets in no more than 1.85 percent of workspaces, about 100,000, and that stolen AI provider keys were then used to rack up an estimated $740,000 in unauthorized charges. Database logs showed the attacker's queries picked out variables named like AI provider keys. Railway said it would pay whatever AI providers declined to refund. It has not named the attacker. The breach was not isolated. Wiz counted at least nine AI developer platforms that disclosed incidents in October, and iTnews reported that the count had since reached 15.

The intrusion started in Railway's build system. The company said the attacker began probing it at 06:50 UTC on October 20 and, at 07:28 UTC, used an unknown bug to partly break out of the file isolation that separated builds sharing one virtual machine. That gave it read access to some files on the host, including a credential build servers used to push finished images and talk to certain internal services. An alert about odd calls to a registry service paged the on-call engineer at 13:58 UTC, hours after the first exploit. The engineer followed the calls back to the credential and the build behind it, and the response team shipped a fix and paused builds. Later forensics showed dummy-account signups from October 18 that all failed, Railway said.

That credential should have covered build work and nothing else. Railway said its self-hosted Temporal cluster, which scheduled build tasks, treated it as a trusted client regardless. The attacker used this to read the saved records of 353 builds, along with whatever variables and secrets those builds had been given. The credential could also fetch cached repository snapshots, and a recent build of Railway's support site let the attacker pull a copy of the internal monorepo. Railway wrote that the copy let the attacker run agent fanouts to hunt for exploits and move around quickly. The company swapped out the credential at 17:28 UTC and reopened builds, unaware of the code copy. It noticed only when the attacker started touching endpoints that had sat unused for weeks, months or years.

Reading that code, the attacker found a misconfigured OIDC binding in one of Railway's cloud environments. The binding helped its deployment pipeline obtain short-lived cloud credentials. Early on October 21, at 03:26 UTC, the attacker abused it to get one. That credential let it collect two internal credentials: one that could read encrypted variables out of a production database from inside the private network, and an SSH key the pipeline used to push binaries. The key opened an orchestration machine that held a longer-lived credential for decrypting customer variables, since the machine needed it to launch customer workloads. The attacker copied encrypted records between 04:07 and 05:21 UTC and decrypted some during two windows ending at 05:14 and 07:15 UTC. Railway said the attacker was fully out by 09:24 UTC.

Railway's logs name affected environments rather than individual variables, so it treated the 100,000 figure as a ceiling. The decrypted material also covered linked-account tokens for 1,852 users, namely bring-your-own-key agent keys and GitHub OAuth tokens. Railway said it reset each one, told each user, and found no sign-ins to Railway accounts using them. One query also matched cloud, database and payment credentials. Railway said forensics did not show customer databases being opened or customer repositories being downloaded. From 09:25 UTC on October 21 it asked eight providers, among them GitHub, OpenAI, Google and Stripe, to revoke keys that might be exposed, and because it could not tell which were taken, it handed over hashes of every key it stored. Railway believed the keys were bound for services that relay or resell AI access, possibly for distillation. Whether the attacker operated any of those services remained unknown, it said.

Who absorbed the cost varied by provider. Railway said AWS and Google applied their fraud policies and began refunds, OpenAI and SpaceXSI were weighing claims one at a time, and Anthropic talks were still open. OpenRouter held to its no-refund terms. Railway said it would cover Anthropic key costs for now and all OpenRouter costs. The Hacker News pointed out that the report did not explain how the $740,000 estimate was built. Wiz showed what happens to keys after they leave a victim. In two enterprise cases it tied to one of the vendor breaches, the first misuse came within 30 minutes and was a single test call from a home internet address. One key later drove about 800,000 Amazon Bedrock calls over thirty hours, the other about 1.7 million over thirteen. Wiz put those two cases at more than $100,000 at list prices.

The incident underscores how much risk piles up when a hosting or build provider holds a customer's secrets. Encryption at rest did not help, because a machine the attacker reached held the means to decrypt. Auditors reviewing third-party arrangements can ask where AI keys, cloud credentials and payment tokens are stored, who at the vendor can decrypt them, and whether build and pipeline credentials are limited to the single job they serve. Risk teams can confirm that every AI key has a spend limit and a usage alert, since Wiz saw a narrowly scoped key policy hamper abuse of one stolen key, and that rotation happens at the issuing provider, which Railway noted is separate from filing a charge report. Contracts deserve a check for notification timing and for who carries fraudulent usage, given that Railway alerted providers before it had told users broadly and has promised a fixed deadline for broad notice next time. Finally, teams should list every platform that stores their secrets, since attackers hunted the same kind of variable across many of them.