Summary
Railway, a platform-as-a-service provider, disclosed that AI provider keys customers stored on its platform were stolen in an October 2026 breach and used for an estimated $740,000 in unauthorized spending. The company says it will pay those charges itself when an AI provider will not refund them. The report does not explain how the estimate was calculated or what period it covers.
Attack Timeline (UTC, October 2026)
- Oct 20, 07:28: The attacker exploited a previously unknown flaw to partly escape filesystem isolation around a build and read files on the host VM.
- Oct 20, 13:58: An on-call engineer was paged about unusual registry-service calls, about six and a half hours after the first exploit.
- Oct 20-21: A build credential accepted as trusted by an internal Temporal system gave access to other builds' histories and cached code snapshots, including a copy of the internal monorepo.
- Oct 21, 03:26: A misconfigured OIDC binding in a cloud environment yielded short-lived cloud credentials, then an encrypted-variable read capability and an SSH key.
- Oct 21, 04:07-07:15: The attacker pulled encrypted variables from a production database, searching for names matching AI provider keys, and decrypted some using the orchestration machine's KMS credentials.
- Oct 21, 09:24: The attacker was fully removed.
Railway's preliminary report of October 22 gave different times.
What Was Exposed
- Decrypted environment variables in at most 1.85% of workspaces (about 100,000). Railway calls this an upper bound because logs show which environments were exposed, not which variables.
- Linked-account tokens for 1,852 users, including BYOK agent keys and GitHub OAuth tokens. All were reset and users notified.
- Cloud, database, and payment service credentials matched one query.
- Stored histories of 353 builds, including variables and secrets passed to them.
Railway reports no customer databases accessed, no sign customer repositories were downloaded, and no logins to customer accounts using stolen credentials.
Refund Position by Provider
| Provider | Status |
|---|---|
| AWS Bedrock, Google Gemini | Existing fraud refund policies apply; refunds started |
| OpenAI, SpaceXSI | Case-by-case review; file a claim and send the case ID to Railway |
| Anthropic | Talks ongoing; Railway covers costs meanwhile |
| OpenRouter | No-refund policy stands; Railway covers all related costs |
Railway believes the stolen keys were used by services that relay or resell AI provider access for distillation. It has not confirmed who ran those services or named the attacker.
Remediation by Railway
- Each build now runs in its own short-lived VM.
- Build credentials can push only one specific image to the registry.
- All users were moved to the new build system after the hardening team found a second exploit within an hour of the original fix.
- An FBI IC3 complaint was filed and a forensics firm engaged. Indicators of compromise are shared privately until law enforcement agrees to publication.
Recommended Actions for Customers
- Revoke and replace any sensitive variable stored on Railway before October 21, and rotate keys with the issuing provider. Filing a charge report does not revoke a key.
- Remove public network access to databases.
- Review GitHub audit logs and which apps can access your account.
- Review registry audit logs, such as Docker Hub.
- Report unrecognized charges through Railway's charge report form, and set spend limits and alerts on AI provider accounts.