Railway estimates $740,000 in fraudulent AI charges after breach

Railway estimates that stolen customer credentials generated about $740,000 in unauthorised AI usage after its October security breach. Its full post-mortem, published on 10 November, puts potential environment-variable decryption at an upper bound of about 100,000 workspaces, or 1.85% of its workspaces.

The hosting company describes a chain from a build-isolation flaw to internal credentials, source code and a misconfigured cloud identity relationship. Railway says the attacker specifically sought AI-provider keys, and that the resulting response became a roughly 26-hour race between attacker and defender automation.

A build escape exposed a route into internal systems

The attacker first exploited Railway’s build infrastructure on 20 October, according to the company’s timeline. Multiple builds then ran on the same virtual machine with isolation between them. A previously unknown flaw allowed partial escape from that filesystem isolation and access to a credential used by the build servers.

That credential could reach more than its intended build-completion functions. Railway says an internal workflow service accepted it as a trusted client, allowing the attacker to read a limited set of stored build histories. The histories included information and credentials associated with those builds.

One retrieved build related to Railway’s own internal software repository. Access to a repository snapshot gave the attacker a detailed view of the platform’s code. Railway says that knowledge accelerated searches for further entry points as engineers revoked credentials and hardened the affected systems.

A cloud identity error enabled a second escalation

Railway says an incorrectly configured OpenID Connect trust relationship supplied the attacker with a short-lived cloud credential on 21 October. OpenID Connect is used here to let a workload prove its identity and obtain access to another system. The security of that exchange depends on which workloads the receiving system agrees to trust.

The attacker used the resulting access to retrieve other internal credentials and reach an orchestration machine. That machine needed a decryption credential to provision customer workloads. Railway says the attacker obtained it and used the access to query encrypted customer variables and decrypt a subset.

Encryption therefore depended on the surrounding identity and access controls remaining intact. The post-mortem describes the attacker crossing those controls through several different systems, while the response team worked to remove each route.

The 100,000-workspace figure is an exposure ceiling

Railway’s logs establish an upper bound for environments whose variables could have been decrypted. The company reports about 100,000 potentially affected workspaces, equivalent to at most 1.85%. Its logs identify environments, so that estimate describes the scope of potential exposure at workspace level.

The company separately reports decrypted linked-account tokens for 1,852 users, including bring-your-own-key agent credentials and GitHub OAuth tokens. Railway says it reset those tokens and notified the affected users. Workspaces and users are separate units in the report and should be read as separate measures.

Stolen AI keys have a direct resale value

Railway believes the attacker was collecting AI-provider credentials for resale and use in model distillation. That is the company’s assessment of intent, based on its forensic investigation. Distillation uses outputs from one model as learning material for another, creating demand for large volumes of inference.

Security researchers at Wiz describe a wider campaign against AI developer platforms focused on obtaining inference credentials. Their account connects compromised keys with intermediaries selling access to AI services. A stolen key can therefore generate downstream service charges even when the attacker’s entry point was a separate hosting platform.

The $740,000 estimate shows that consequence in financial terms. Railway says it is working with providers on refunds and will cover breach-related token costs where providers decline reimbursement. The post-mortem gives customers provider-specific instructions for making claims.

The recovery changes the build boundary

Railway says each build now receives a dedicated temporary virtual machine and a credential limited to pushing a specific container image. It also describes rebuilding parts of its deployment infrastructure, tightening identity permissions and moving towards narrowly scoped, short-lived credentials.

The company’s initial October disclosure, covered in our earlier Railway report, urged credential rotation while deployments were paused. The November post-mortem adds the attack sequence, quantified exposure ceiling and reimbursement arrangements.

For affected organisations, replacement credentials and a review of downstream provider activity address the consequences of exposed secrets. Railway’s own changes address the infrastructure that allowed those secrets to be reached in the first place.