Railway Says an Intruder Hunting AI Keys Decrypted Customer Environment Variables in Up to 1.85% of Workspaces, About 100,000, and Tells Users Who Signed Up Before Oct. 21 to Rotate Every Secret

NEW YORK - The cloud deployment platform Railway says an attacker who was inside its internal systems from Tuesday afternoon until early Thursday was after one thing in particular: the API keys its customers store for AI providers.

In a preliminary report published Thursday, Railway's Jacob Cooper and Angelo Saraceno wrote that the attacker reached the company's CI environment, decrypted artifacts that held additional API access and ran an unauthorized query of encrypted customer environment variables, a subset of which were decrypted. At most 1.85% of all workspaces had some environment variables potentially compromised, which Railway put at about 100,000 workspaces.

"We recommend that all customers who signed up prior to October 21 rotate their keys stored on Railway," the company wrote.

A two-day intrusion, hour by hour

Railway says the attack ran from 13:58 UTC on Oct. 20, when monitoring paged the on-call engineer over elevated latency, to 03:32 UTC on Oct. 22, when it confirmed the attacker no longer had access to any internal systems. Within the first afternoon, engineers identified a potential privilege escalation in the build infrastructure and halted build pipelines. At 19:53 UTC that evening they found evidence that the attacker could escalate access at higher scale, across multiple parts of the system in parallel.

The company says early investigation indicates the campaign was "attempting to obtain AI provider API keys to perform distillation attacks," using stolen access to copy model behavior. "Initial evidence leads us to believe that the malicious actor had access to abliterated models and substantial compute resources which enabled them to perform highly sophisticated exploits against our infrastructure," the report says. Railway says it is not yet sharing the specific exploits while the investigation continues.

The decisive hours came early on Oct. 21. Between 04:24 and 05:23 UTC, forensics showed the attacker could pull secrets in encrypted form but could not yet decrypt them. From 05:27 to 07:25 UTC the attacker obtained credentials to Railway's CI environment and decrypted artifacts there. By 09:18 UTC engineers had database evidence of the query against encrypted environment variables. Because the keys were envelope encrypted, Railway says, that query alone cannot show which keys in a given project or service were exposed. Logs from the attacker's payloads showed the specific API key names being sought, and at 09:25 UTC Railway began notifying vendors and asking them to revoke keys.

Who is most at risk

Railway says it reported, out of caution, up to "all of the keys we stored, for all users on Railway" to outside providers, so the number of users hit by upstream revocations is larger than 100,000. It named GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI and Stripe among the providers it worked with, and says it gave GitHub and SpaceXSI every API key present on the platform. "Users being notified by vendors about revocation does not imply that their credentials were impacted by the incident," the report says.

Because the attacker was hunting AI credentials, Railway describes two higher-risk groups: workspaces with a very large number of environment variables, and environments holding many AI keys from vendors. It says the attacker did not log in to individual Railway user accounts, but it is not ruling out access to user source code until the final forensic report. Running deployments stayed online throughout; new builds were paused during triage.

Railway also explains why customers heard about rotation after vendors did. The company says it wanted the attacker out of its running infrastructure before telling users to roll credentials, so the new ones would not be immediately compromised again.

What Railway changed

The company says it rolled all keys and then rolled them again after confirming the intruder was out, rolled credentials for every storage bucket deployed on the platform, rebuilt its infrastructure tooling from validated source, revoked all Railway access tokens, rolled all GitHub App installations and engaged an outside forensics firm. It also moved builds from third-generation isolated multi-tenant environments to fourth-generation single-tenant ones, a rollout it says was planned for next week and was accelerated.

What defenders can do

• Inventory every secret stored as a Railway variable for workspaces created before Oct. 21, rotate it at the issuing provider and revoke the old value, starting with AI provider keys and services that carry many variables.
• Pull provider-side usage and audit logs for those keys from Oct. 20 onward, including AI model usage, GitHub, GitLab and payment platforms, and look for activity that does not match your workloads.
• Follow Railway's checklist: remove public network access to databases, check GitHub audit logs and review all app access, and check audit logs in registries such as Docker Hub.
• Treat a vendor revocation email as a precaution rather than proof of compromise, but confirm the key is truly replaced everywhere it is used, then reconnect GitHub and redeploy services so they pick up the new values.
• Record the intrusion window, 13:58 UTC on Oct. 20 to 03:32 UTC on Oct. 22, in your own incident ticket so later hunts and the final Railway report can be matched against it.