Loading page…
The November 10 incident report traces the theft through build infrastructure and cloud permissions. Refund arrangements vary by AI provider.
Listen to this story
Railway says an attacker used credentials recovered from its build and internal task systems to access its decryption service on October 21, exposing customer environment variables that could include AI keys. The company estimates unauthorized AI usage at $740,000 and says up to 1.85% of workspaces may have been affected; that is an upper bound because logs identify environments, not specific variables. Railway will cover costs providers do not refund, while customers must revoke compromised keys themselves.
The intrusion began October 20, 2026, with a build-system flaw; stolen code helped the attacker find a misconfigured cloud identity rule the next day.
Railway says 1,852 users’ linked-account tokens were exposed and reset, and found no evidence that customer databases were accessed or code repositories downloaded.
AWS Bedrock and Google Gemini account teams have begun refunds; OpenAI reviews claims individually, while Railway covers breached Anthropic-key costs and breach-related OpenRouter charges.
Railway’s October breach left customers facing an estimated $740,000 in unauthorized AI usage charges, the company disclosed in a November 10 incident report. The app-hosting platform says it is seeking provider refunds and will cover costs where providers refuse. The attacker reached and decrypted customer secrets through Railway’s internal infrastructure.
Railway stores application settings and secrets, including AI access keys, as environment variables. Its investigation found that the attacker’s database searches specifically prioritized AI-provider credentials.
The first successful intrusion came on October 20, 2026. A previously unknown flaw let the attacker partly escape the filesystem boundary around a build and steal a build-server credential, according to Railway.
That credential also worked in Railway’s internal task system. The attacker read histories from 353 builds, including secrets, and retrieved Railway’s internal code repository. Railway patched the flaw and replaced the credential that evening, but the stolen code helped the attacker find another opening.
On October 21, a misconfigured cloud identity rule opened access to more credentials and a machine used to start customer workloads. It held a credential authorized to request decryption of customer variables. Encryption therefore did not prevent the theft: the attacker could use Railway’s own decryption service.
About 100,000 workspaces could have had variables decrypted. This is an upper bound: logs identify environments, not individual variables.
Railway reset these tokens and notified each user.
Railway cut off decryption access and stopped builds again on October 21. It says the attacker had no customer-data access after 09:25 UTC that day. Builds returned for all plans on October 22 after infrastructure hardening.
Its forensics found no evidence that customer databases were accessed or customer code repositories downloaded. Each build now runs in its own short-lived virtual machine, with credentials limited to uploading one specific image, The Hacker News reported.
The reimbursement pledge changes Railway’s earlier position. An October 26 update said it could not refund spending on compromised keys. Its current arrangements vary:
Railway also advises customers to revoke and replace sensitive variables stored before October 21 through their issuing providers. Submitting a charge report does not revoke a key.
Loading discussion...
Join the conversation
Explain how responsibility should be shared with the AI provider.
Be the first to share a perspective or an experience.
Reader comments
Newest comments first. Replies stay oldest first.