Railway says an October security attack exposed a subset of customer environment variables and led to roughly $740,000 in unauthorized AI-provider usage.
The platform-as-a-service company published a detailed incident report on November 10 after an October 22 preliminary report. Railway said attackers could have decrypted variables for at most 1.85% of workspaces, about 100,000, and that AI provider credentials appeared to be the primary target.
Railway described the 100,000-workspace figure as an upper bound because its logs identify affected environments, not every individual variable. The company also said the attacker read stored histories for 353 builds on October 20, including sealed variables.
Railway said its investigation found no logins to Railway accounts using credentials taken in the incident. The more damaging issue was access to stored environment variables and linked-account tokens. The company said it reset linked-account tokens for 1,852 users, notified those users, and began coordinating with providers whose keys may have been exposed.
How the attacker reached customer variables
The report describes two linked access paths. First, the attacker exploited a previously unknown build-infrastructure vulnerability that let them partially escape filesystem isolation and read some files on a host virtual machine. Railway said that exposed an internal build credential and later a copy of Railway’s monorepo, giving the attacker a privileged view of how its systems worked.
The second path came through an incorrectly defined OIDC binding in one of Railway’s cloud environments. Railway said the attacker used it to obtain short-lived cloud credentials, retrieve internal credentials, reach a database that stored encrypted environment variables, and decrypt some variables with a longer-lived credential found on an orchestration machine.
Railway said the attacker began creating accounts and probing on October 18. Those early attempts failed. The company found no evidence of attacker access to customer data after 09:25 UTC on October 21. Builds were halted twice during the response, user sessions and tokens were invalidated on October 21, and builds for all plans were restored by 22:49 UTC on October 22.
Who is paying for the unauthorized AI usage
Railway estimated unauthorized spend on stolen keys at about $740,000. In its November 10 report, the company said AWS Bedrock and Google Gemini account teams had initiated refunds under fraud policies, while OpenAI and SpaceXSI were reviewing claims case by case.
Anthropic discussions were still ongoing when Railway published the report, so Railway said it would cover Anthropic breached-key costs in the meantime. OpenRouter enforced its no-refund policy. Railway said it would cover breach-related token losses whenever the provider declined to reimburse them, including OpenRouter’s.
The wider pattern: AI keys are monetizable secrets
Security firm Wiz placed Railway in a group of at least nine AI developer platforms that disclosed incidents during October. Wiz said public reports showed targeted exploitation of stored environment variables, especially credentials that grant AI access, and connected the activity to LLMJacking, where stolen model access is abused or resold.
Wiz did not independently attribute its downstream abuse cases to Railway, and Railway’s report did not name a specific threat actor. The overlap is the operating model: stored AI keys on developer platforms can be converted into billable model traffic after theft.
Anthropic describes distillation as training a less capable model on the outputs of a stronger one. Railway said its forensic investigation suggests the stolen AI credentials were likely passed to distributed transfer stations for use in distillation.
What Railway told customers to do
Railway’s October 22 preliminary report recommended that all customers who signed up before October 21 revoke and reapply sensitive environment variables stored on Railway. The company also advised customers to remove public network access to databases, rotate sensitive variables and keys, review GitHub audit logs and app access, and check container registry audit logs for unexpected activity.
In the November 10 report, Railway asked customers to report charges they did not make while it works with AI providers and cloud vendors on remediation.
The lesson beyond Railway
A stolen AI key can spend against the provider account that issued it, even after the breached platform has contained the intrusion.
For teams storing provider keys in build, deployment, automation, or agent platforms, the practical control set is expanding. Rotation is still necessary, but provider-side spend controls and billing alerts, where available, are becoming financial safeguards. Narrow key permissions, shorter-lived credentials, and a tested emergency rotation path reduce the damage when a stored secret becomes exposed.
Get new small business insights by email
Practical ideas and useful articles to help you make better business decisions.
Tech Help Canada Staff researches, writes, and reviews practical content for business owners and professionals. Our coverage spans business, marketing, SEO, technology, and the tools and systems people use to grow and operate online. We focus on clear, useful information backed by research, hands-on experience, and editorial review. Learn more about our team and editorial standards. Need help with something? Contact Us
