Railway suffered a security breach in October that potentially exposed up to 100,000 workspaces and led to an estimated $740,000 in unauthorized AI usage. The company confirmed that attackers exploited vulnerabilities in its build infrastructure to access customer environment variables, including AI API keys, database credentials, and OAuth tokens.
Railway has since invalidated affected sessions and tokens, and it pledged to cover breach-related costs that third-party providers like OpenRouter and Anthropic do not refund. The incident began on October 20, 2026.
Railway says an attacker targeted AI-provider credentials during its October security breach and could decrypt customer environment variables associated with at most 1.85% of its workspaces, approximately 100,000. The company estimates that stolen keys generated about $740,000 in unauthorized usage and says it will cover breach-related costs that providers do not refund.
The company published its final incident report on November 10, 2026, detailing an attack that began on October 20. The attacker chained a build-isolation flaw, overly broad internal trust and access to secret-decryption credentials.
For affected developers, the immediate tasks are separate: revoke compromised credentials, investigate usage and pursue reimbursement. Filing a refund claim does not disable a stolen key, and a platform’s recovery does not invalidate credentials already copied elsewhere.
What the 100,000-Workspace Figure Means
Railway’s approximately 100,000-workspace figure is an upper bound on potential exposure, not a confirmed count of workspaces whose secrets were stolen or abused.
According to The Hacker News’s account of the report, Railway’s logs identify which environments were exposed but cannot establish which individual variables were accessed. Railway emailed customers it considered at high risk.
The report describes several distinct categories:
Customer environment variables: These can contain AI API keys, database credentials, payment-service secrets and other authentication material.
Stored build histories: The attacker read histories for 353 builds, including variables and secrets supplied to those builds.
Linked-account tokens: Tokens belonging to 1,852 users were exposed, including bring-your-own-key agent credentials and GitHub OAuth tokens. Railway says it reset them and notified affected users.
The 1,852-user count measures a different category from the workspace estimate. It should not be added to 100,000 as though both numbers describe unique affected customers.
Railway also provided some services with every key it held for those providers as a precaution. That widened the population receiving revocation requests beyond the estimated exposure boundary. A provider’s reset notice therefore does not, by itself, prove that an attacker obtained that particular key.
I would treat the workspace estimate as a reason to review credentials, not as a reliable way to decide that a workspace outside a notification list is safe. The logging limitation makes a variable-by-variable clearance difficult.
How a Build Credential Reached Customer Secrets
Railway’s incident timeline starts with probing at 06:50 UTC on October 20. At 07:28 UTC, the attacker exploited a previously unknown vulnerability in its build infrastructure.
At the time, multiple isolated builds could run on the same virtual machine. The flaw allowed a partial escape from filesystem isolation, exposing some files on the host. One contained a credential used by build servers to access internal systems, including the registry where completed images were pushed.
Build Histories Exposed More Than Build Metadata
The stolen credential was intended to authorize build-related work. Railway’s internal Temporal service also accepted it as a trusted client.
Temporal schedules and runs asynchronous tasks. Railway’s stored build-task histories contained useful operational information: repository-scoped GitHub tokens, build variables, secrets and execution metadata. The attacker used an API to read a limited subset of those histories.
The credential could also retrieve cached repository snapshots. That allowed the attacker to copy Railway’s internal monorepo after accessing a build associated with its support platform.
Source code theft mattered because the repository revealed how Railway’s services connected. According to Railway, that visibility helped the attacker identify additional routes through its infrastructure.
A Cloud Trust Misconfiguration Extended the Attack
After examining the code, the attacker found a misconfigured OpenID Connect, or OIDC, binding in a Railway cloud environment. OIDC can let a deployment system exchange an authenticated identity for short-lived cloud credentials. Its security depends on correctly restricting which identities receive which permissions.
At 03:26 UTC on October 21, the attacker exploited that configuration to obtain a cloud credential. From there, the attacker obtained credentials that could read encrypted production variables from inside Railway’s network, plus an SSH key.
The SSH key opened an orchestration machine that held a credential capable of decrypting customer variables, according to The Hacker News’s technical account.
The consequential detail is the chain of permissions. Reading encrypted database records and possessing the ability to decrypt them are separate capabilities. The attacker reached both through successive internal systems. Encryption at rest still leaves a serious exposure path when a compromised environment can obtain both ciphertext and the authority needed to read it.
Railway says it fully evicted the attacker at 09:24 UTC on October 21. It invalidated every user session and token later that day and restored builds across all plans by 22:49 UTC on October 22.
AI Keys Were the Target, but Other Secrets Matter
Railway says the attacker’s database queries specifically prioritized AI-provider credentials. Some queries also matched cloud, database and payment-service credentials, according to BleepingComputer’s report.
Railway reported no evidence that the attacker accessed customer databases or downloaded customer Git repositories. Those findings concern observed activity; they do not make exposed database passwords or repository tokens safe to retain.
The company notified GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI, Google and Stripe so potentially compromised credentials could be revoked.
Railway also believes the attacker sought AI credentials for sale to distributed transfer stations for use in model distillation. Distillation uses outputs from one model to help train another.
That remains Railway’s assessment of the likely destination and purpose. The published evidence does not identify the operators of those services or establish that every instance of later misuse came from the original attacker. There is insufficient support to attribute the breach to a particular resale network.
Refund Handling Depends on the AI Provider
Railway’s reimbursement position changed during its response. An October 26 update said it could not refund spending performed with compromised API keys and directed customers toward providers. Its final report says it will cover breach-related charges when providers will not refund them, according to The Hacker News.
The arrangements described in that report differ by provider:
Provider
Refund position reported in November
Customer action
AWS Bedrock
Existing fraud-refund policy applies; account teams had started refunds
Contact AWS through the relevant account or support channel
Google Gemini
Existing fraud-refund policy applies; account teams had started refunds
Pursue the claim with Google
OpenAI
Claims reviewed case by case
File with OpenAI, then give Railway support the case ID
SpaceXSI
Claims reviewed case by case
Submit the claim through the support route described by Railway
Anthropic
Discussions were ongoing; Railway said it would cover affected costs in the meantime
Report the breach-related charges to Railway
OpenRouter
Maintains its no-refund policy; Railway said it would cover breach-related costs
Report the charges to Railway
These are reported arrangements at publication, not evidence that every claim has been approved or paid.
Customers should use the charge-report process referenced by Railway and preserve provider case IDs, usage records, invoices and the timing of key revocations. That documentation helps connect disputed usage to the affected credential.
The $740,000 figure is Railway’s estimate, not an independently audited total. The published reporting does not explain its calculation method, the period covered or how many keys generated the charges. It also identifies no claim deadline or cap and does not resolve whether customers must pay disputed bills while claims are under review.
What Developers Should Do Now
Railway’s advice is to revoke and replace sensitive variables stored on the platform before October 21. The targeting of AI keys makes those urgent, but the broader credential exposure warrants a wider review.
Revoke keys with their issuing providers. Replacing an environment variable changes what an application uses next. It does not necessarily disable the old credential. Revoke the old key, deploy its replacement and check that dependent applications still work.
Review billing and usage logs. Look for unexpected model calls, spending increases and unfamiliar activity around and after the incident. Save the records needed for a refund claim.
Review GitHub access. Check audit logs, authorized OAuth applications and repository access. Railway’s linked-token resets are separate from reviewing other credentials your applications may have stored.
Check database and registry exposure. Railway recommended removing public database access and reviewing registry audit logs, including services such as Docker Hub.
Separate the reimbursement task from containment. Submit the charge report and contact the relevant provider, but continue credential rotation while the claim is pending.
For longer-term protection, I would prioritize narrowly scoped credentials and provider-side spending controls where available. A stolen key with access to one project and a constrained budget presents fewer opportunities for abuse than an unrestricted account-wide credential. Whether a particular limit actually stops usage or merely sends an alert needs checking with that provider.
An external secret manager can help centralize rotation and access policies. It still requires a constrained access path: moving a long-lived key into a vault offers limited protection if a compromised build can freely retrieve it. Build histories, caches and deployment automation belong in the secret-storage review too.
Railway’s Rebuild Targets the Failed Trust Boundaries
Railway says it rebuilt CI and secret-decryption controls, introduced dedicated ephemeral build virtual machines and narrowed credential scope after the incident, according to its final report.
Those changes address different stages of the documented chain. Short-lived, dedicated build machines change the environment in which the initial escape occurred. Narrower credentials reduce the internal services a stolen build identity can reach. Tighter decryption controls address the final step that turned encrypted records into usable secrets.
The report describes Railway’s remediation; it is not an independent validation of the rebuilt infrastructure.
For developers assessing their own deployments, the useful question is specific: what can a compromised build identity read, invoke and decrypt? Railway’s account shows why reviewing that entire path is more useful than checking only where the production API key is stored.
Frequently Asked Questions
3 questions
1
How Do I Know Whether My Workspace Was Affected?
Railway says it emailed high-risk customers. The approximately 100,000-workspace figure is an upper bound, and precautionary provider revocations reached a wider group. Review notifications alongside the secrets your workspace held.
2
What Should I Do About Unauthorized AI Charges?
Revoke the affected key, preserve usage and billing records, and report the charges to Railway and the provider. OpenAI claimants should also give Railway their provider case ID.
3
Should I Rotate Only My AI Keys?
Railway advises replacing sensitive variables stored before October 21. AI keys were the priority target, but the attacker’s searches also covered cloud, database and payment credentials.
