Railway Says Stolen Customer AI Keys Led to $740,000 in Estimated Unauthorized Usage Charges

Summary

Railway reported that customer AI-provider keys stolen during its October 2026 breach generated an estimated $740,000 in unauthorized usage charges. The platform committed to covering breach-related charges where providers would not issue refunds. The supplied reporting does not explain how the estimate was calculated or what period it covers, so the amount should be treated as a reported estimate rather than a fully documented loss total.^[0]

The intrusion combined exploitation of a previously unknown build-filesystem isolation flaw with credential reuse across internal services and an incorrectly configured cloud OIDC binding. Beginning at 07:28 UTC on October 20, the attacker progressed from limited host-file access to Railway's internal source code, cloud credentials, production encrypted variables, and credentials capable of decrypting those variables through a cloud KMS. Railway reported full eviction at 09:24 UTC on October 21.^[0]

Railway placed the upper bound on workspaces whose variables were decrypted at approximately 100,000, or 1.85%, while acknowledging that logs identify environments rather than individual exposed variables. Additional exposure included linked-account tokens for 1,852 users and histories for 353 builds. Railway reported no detected customer-account logins using stolen credentials, no forensic evidence of customer-database access, and no indication of customer-repository downloads; those findings do not negate the confirmed secret exposure.^[0]

Railway says all weaknesses used by the attacker are closed and has moved builds into individual short-lived virtual machines with image-specific push credentials. Customers are nevertheless advised to revoke and replace sensitive credentials stored before October 21. Attribution remains unresolved: Railway suspects use of stolen keys by AI-access relay or resale services, but has not established that the intruder operated them. The detailed technical account supplied here is the aggregator's reporting of Railway's findings, rather than a separately supplied vendor report.^[0]

Attack chain

1. 1. Build isolation exploitation and credential theft: At 07:28 UTC on October 20, the attacker exploited a previously unknown flaw to partially escape a build's filesystem isolation and read some files on its host virtual machine. This exposed a credential used by build servers to push completed images and access certain internal systems.^[0]
2. 2. Internal build-history and source-code access: Railway's internal Temporal system accepted the build credential as a trusted client, allowing the attacker to read stored histories of other builds. The credential also retrieved cached code snapshots, exposing Railway's internal monorepo. Railway says the source code helped the attacker understand the platform and identify further weaknesses.^[0]
3. 3. Cloud credential acquisition through OIDC misconfiguration: After reviewing the internal code, the attacker identified an incorrectly configured OIDC binding used by the deployment system to obtain short-lived cloud credentials. The attacker exploited that binding at 03:26 UTC on October 21 to obtain a cloud credential.^[0]
4. 4. Access to production secrets and orchestration infrastructure: Using the cloud credential, the attacker obtained two additional credentials: one able to read encrypted production variables when used from the internal network, and an SSH key. The SSH key opened an orchestration machine that stored a credential capable of decrypting customer variables for workload startup.^[0]
5. 5. Targeted encrypted-variable collection: Between 04:07 and 05:21 UTC on October 21, the attacker retrieved encrypted variables from the production database, searching for variable names associated with AI-provider keys. One query also matched cloud, database, and payment-service credentials.^[0]
6. 6. KMS-backed decryption: The attacker used credentials from the orchestration machine with the cloud KMS to decrypt some collected variables during two reported windows: 04:42–05:14 UTC and 06:36–07:15 UTC on October 21.^[0]
7. 7. Unauthorized use of stolen AI credentials: Stolen customer AI-provider keys were subsequently associated with an estimated $740,000 in unauthorized usage. Railway believes the credentials were used by services relaying or reselling AI access for distillation, but the reporting supplies no precise misuse period and does not establish whether the intruder operated those services.^[0]

Disclosure timeline

How it works

The initial flaw weakened filesystem isolation around a build sufficiently to expose some host-virtual-machine files. The reported result was theft of a build-server credential; the evidence does not describe a complete virtual-machine escape or provide a CVE identifier or exploit implementation.^[0]

The stolen credential crossed service trust boundaries. Although intended for build work, it was accepted by Temporal as a trusted client and could retrieve cached source snapshots. This exposed both build histories containing secrets and Railway's internal monorepo, which Railway says accelerated the attacker's discovery of additional weaknesses.^[0]

The cloud pivot depended on an incorrectly configured OIDC binding in Railway's deployment environment. Exploiting that binding yielded a short-lived cloud credential, which exposed a production-database read credential and an SSH key. The SSH-accessible orchestration machine then supplied credentials authorized to decrypt customer variables.^[0]

Customer variables used envelope encryption: each environment's variables were encrypted with an environment-specific key, and those keys were encrypted under a root key held in a cloud KMS. The attacker obtained both encrypted database material and operational credentials that could invoke the decryption path. Railway says disabling the abused credential prevents later decryption of copied material that had not already been decrypted.^[0]

Railway's hardening team produced a modified version of the original escape within an hour of its patch. The company cited this as one reason to migrate all users to a new build system that adds a dedicated short-lived virtual machine per build and limits each build credential to pushing one specific image.^[0]

Affected versions and patch status

Key takeaways

• The central technical failure was a sequence of trust-boundary crossings: a build-isolation flaw exposed a credential that unlocked internal histories and source code, followed by an OIDC misconfiguration and access to operational decryption credentials. Encryption at rest did not prevent exposure once the attacker reached the authorized decryption path.^[0]
• Exposure figures require careful interpretation. Approximately 100,000 workspaces is an upper bound, not a confirmed count of individual keys stolen, and precautionary provider resets reached beyond that population. The reported $740,000 is an estimate without a disclosed calculation method or coverage period.^[0]
• No named actor or actionable indicator values are supplied. Railway reported private indicator sharing, an FBI IC3 complaint, and continuing specialist forensic work; its hypothesis about AI-access resale or relay services does not establish the intruder's identity or control of those services.^[0]
• Wiz places Railway within a wider October cluster involving at least nine AI developer platforms, but that context is not independent corroboration of Railway's detailed attack chain. The aggregator reports no single shared flaw or dependency linking the incidents.^[0][14]

Defensive actions

• Revoke and replace sensitive credentials stored as Railway variables before October 21, using the issuing provider's revocation or rotation process.: The attacker decrypted customer variables and searched beyond AI keys for cloud, database, and payment credentials. Railway explicitly recommends replacement, and submitting a charge report does not invalidate a stolen key.^[0]
• Remove public network access to customer databases.: Railway specifically recommends this measure following the breach, in which database credentials were among the credential classes matched by an attacker query. The company reported no forensic evidence that customer databases were accessed.^[0]
• Review GitHub audit logs and applications authorized to access customer accounts.: GitHub OAuth tokens were included in the exposed linked-account material. Railway reset the affected tokens and recommends audit-log and application-access review, despite reporting no indication that customer repositories were downloaded.^[0]
• Review audit logs in container registries, including Docker Hub.: Railway includes registry audit review in its incident-specific customer recommendations; build histories containing variables and secrets were among the exposed data.^[0]
• Report unauthorized AI usage through Railway's charge-report process and follow the relevant provider's refund procedure separately from credential rotation.: Railway reported an estimated $740,000 in unauthorized usage and committed to covering breach-related charges providers would not refund. The supplied reporting identifies no stated claim cap or deadline and no clear requirement concerning payment of disputed charges while claims are reviewed.^[0]
• Use the refund route documented for each AI provider rather than assuming a uniform policy.: The article reports fraud-refund coverage and initiated refunds for AWS Bedrock and Google Gemini; case-by-case review for OpenAI and the provider labeled SpaceXSI; ongoing Anthropic discussions with interim Railway coverage; and Railway coverage of breach-related OpenRouter costs under OpenRouter's no-refund policy. OpenAI claimants are instructed to pass their case ID to Railway support.^[0]
• Do not treat a provider revocation notice alone as confirmation that a particular key was exposed.: Railway supplied some providers with every key it held for their services as a precaution, leading to reset requests reaching more than 100,000 users. Its logs establish exposed environments, not the individual variables accessed.^[0]