"Railway is unable to refund customers for spend performed with compromised API keys," the company told customers on October 26 — even as it says it will cover charges when an AI provider refuses refunds.
Timeline of the October 20–21 intrusion
According to Railway's incident report, the intrusion began at 07:28 UTC on October 20 when an attacker exploited a previously unknown flaw to partly escape filesystem isolation in the platform's build system and read files on the host virtual machine. That initial access yielded a build credential used to push images and reach internal systems. An on-call engineer was paged at 13:58 UTC the same day after an alert flagged unusual calls to a registry service.
The attacker used the build credential to read stored build histories and fetch cached snapshots of code, producing a copy of the company's internal monorepo that, Railway says, helped the attacker find further exploits. After scanning that code, the attacker exploited a wrongly configured OIDC binding in a cloud environment to obtain a short-lived credential at 03:26 UTC on October 21. Using that, the attacker took two more credentials from the cloud environment: one that could read encrypted variables from a production database when used inside the internal network, and an SSH key that opened an orchestration machine. Between 04:07 and 05:21 UTC on October 21 the attacker pulled encrypted variables from the database; using the orchestration machine's credential with the cloud KMS, some variables were decrypted between 04:42–05:14 UTC and again between 06:36–07:15 UTC. Railway removed the attacker at 09:24 UTC that day.
Railway notes these times differ from a preliminary October 22 report that had dated the incident from 13:58 UTC on October 20 and placed decryption after 05:27 UTC.
What the attacker accessed and what Railway found
- The attacker searched database records for AI provider keys and decrypted variables in at most 1.85% of workspaces — Railway estimates that as about 100,000 workspaces, which it treats as an upper limit because logs show which environments were exposed but not which variables were exposed.
- Railway says the decrypted data included AI provider keys and linked-account tokens for 1,852 users — specifically BYOK agent keys and GitHub OAuth tokens. All of those tokens were reset and the affected users notified; Railway found no logins to customer accounts using those stolen credentials.
- The attacker also read the stored histories of 353 builds, including variables and secrets passed to those builds, and one database query matched cloud, database, and payment service credentials.
- Railway's forensics did not show any customer databases being accessed, and there was no indication that customers' code repositories were downloaded.
- Each environment's variables were encrypted with that environment's own key, and those keys are, in turn, encrypted by a root key stored in a cloud provider's key management service (KMS). Railway says any data the attacker copied but did not decrypt can no longer be decrypted because the credential the attacker used has been disabled.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadRefunds, estimated losses, and who will pay
Railway reported an estimated $740,000 in unauthorized usage charges tied to stolen AI provider keys. The company's incident report does not specify how that $740,000 figure was estimated or what period it covers.
Railway asked customers to report charges they did not make through a charge report form that nevertheless states the company "is not responsible for usage of these keys." The form and the incident report set no stated cap or deadline for claims, and neither documents whether customers must pay disputed charges while a claim is under review.
Refund handling differs by AI provider, per Railway's report:
- AWS Bedrock: AWS's existing refund policy covers fraud, and AWS account teams have started refunds.
- Google Gemini: Google's existing refund policy covers fraud, and Google account teams have started refunds.
- OpenAI: Refunds are reviewed on a case-by-case basis; customers file a claim with OpenAI then pass the case ID to Railway support.
- SpaceXSI: Refunds are reviewed on a case-by-case basis and customers submit claims to the same support team.
- Anthropic: Talks were still underway at the time of the report; Railway said it will cover costs from breached Anthropic keys in the meantime.
- OpenRouter: OpenRouter maintains a no-refund policy in its terms of service; Railway said it will cover all OpenRouter-related costs resulting from the breach.
Railway also said it would escalate refund requests with providers when customers ask, and that it will pay charges itself when an AI provider will not refund them.
What Railway told customers to do and platform changes
- Customers were instructed to revoke and replace any sensitive variable stored on the platform before October 21, and to revoke or rotate keys with the provider that issued them — the charge report does not revoke keys automatically.
- Railway advised removing public network access to databases, checking GitHub audit logs and which apps can access accounts, and checking audit logs in registries such as Docker Hub. Most of this guidance dates from the company's October disclosure and the report published the following day.
- Out of caution, Railway gave some providers every key it held for their services, which resulted in reset requests reaching more than 100,000 users; the company notes a revocation notice from a provider does not by itself mean a key was exposed.
- On the platform side, Railway says every build now runs in its own short-lived virtual machine on top of the prior isolation, and each build's credentials can push only one specific image to the registry. Railway moved every user to the new build system at once after the team developed a second exploit variant while hardening the original escape.
How technologists, AI providers, and affected customers are positioned
- Technologists and security teams: Railway's account of chained failures — a build escape, misuse of a build credential, exposure of an internal monorepo, a misconfigured OIDC binding, and use of a KMS-capable credential — underscores the need to review isolation of build infrastructure, audit short-lived credential acceptance, and inventory where encrypted variables can be decrypted.
- AI providers named in the report (AWS Bedrock, Google Gemini, OpenAI, SpaceXSI, Anthropic, OpenRouter): Their refund policies and responsiveness already determine who bears the direct cost of unauthorized AI use; Railway's report documents a mix of automatic refunds, case-by-case reviews, and refused refunds that Railway says it will cover itself.
- Affected customers and platform users: Railway asked customers to report unrecognized charges via the charge report form, to rotate or revoke keys with issuing providers, and to check database network exposure and third-party registry and repository audit logs. Railway reset linked-account tokens it found and notified the impacted users.
Railway says every weakness the attacker used is now closed. The company filed a complaint with the FBI's IC3, is working with a specialist forensics firm, and is sharing indicators of compromise privately pending law enforcement agreement to publish them. Railway also said it believes the stolen credentials were used by services that relay or resell access to AI providers for use in distillation, but it has not established whether the attacker ran those services and has not named the attacker.
