Threat intel

Railway, the platform as a service (PaaS) that builds and runs apps from a Git repository, disclosed on October 21 that an unauthorized party reached the systems that store customer environment variables. The intruder pulled encrypted variables and, for some workspaces, decrypted them. Railway's preliminary report of October 22 puts the ceiling at 1.85% of all workspaces, about 100,000, and says the attacker was after AI provider API keys to use for model distillation.

If you or your team signed up for Railway before October 21, Railway asks you to rotate every key stored there. It cannot tell you which values were decrypted, so a missing notification email does not mean you were spared. Running services stayed up throughout, but builds and deployments were paused while Railway contained the intrusion.

How it works

A Railway environment variable is a name and value attached to a service, such as OPENAI_API_KEY or DATABASE_URL. Railway stores the values encrypted and injects them into the build and the running container, so its own build and deploy systems must be able to decrypt them. That ability is what the attacker went for.

Railway has not published the entry point. Its timeline says the attack window opened at 13:58 UTC on October 20 with a privilege escalation in build infrastructure; Railway halted build pipelines and declared an incident at 17:03 UTC. By early October 21 the attacker could pull secrets in encrypted form but not decrypt them. From 05:27 UTC they obtained credentials from Railway's continuous integration (CI) environment and decrypted artifacts that held further API access. Between 07:25 and 09:18 UTC, Railway's database shows an unauthorized query of encrypted variables, a subset of which was decrypted with the stolen credentials.

The variables were envelope encrypted, meaning each value is encrypted with a data key that is itself encrypted by a higher key. Railway says this isolation is why it can cap exposure at 1.85% of workspaces, and also why the query record alone cannot show which specific keys were decrypted. It names two higher-risk groups: workspaces with a very large number of variables, and environments holding many AI vendor keys.

Sealed variables are included: Railway's docs say a sealed value is hidden from the UI and API but still provided to builds and deployments.

What the attacker was after

Railway says early evidence points to theft of AI provider API keys for distillation, where stolen access to a premium model is used to generate large volumes of output to train a cheaper copy. Railway ties the intrusion to a wider run of attacks on platform companies aimed at AI inference providers; Zeabur and OpenCode disclosed thefts of stored keys earlier this month.

At 09:25 UTC on October 21 Railway asked vendors to revoke keys, sending every key it held for each service as a precaution. It names GitHub, GitLab, Anthropic, OpenAI, OpenRouter and Stripe among them. More than 100,000 users therefore got revocation notices from vendors, and Railway says a notice "does not imply that their credentials were impacted."

On its own side, Railway rolled all GitHub App installations, rolled credentials for all storage buckets it hosts, revoked all Railway access tokens and invalidated user sessions. It says individual accounts were not logged into. It has not ruled out access to customer source code. The attacker lost all internal access at 03:32 UTC on October 22, nearly 38 hours after the window opened.

What to do

Use 13:58 UTC on October 20 as the start of every log search, not the disclosure date. Treat any rotation you made before 03:32 UTC on October 22 as void, because the attacker was still inside Railway when you saved the new value.

1. List what Railway held. Open every project, environment and service, including PR environments and idle services, and export the variable names. Check Project Settings, Shared Variables too, and follow reference variables such as ${{ Postgres.DATABASE_URL }} to the service that holds the real secret.

2. Rotate the keys that open other systems first. GitHub and GitLab tokens, deploy keys, cloud access keys and container registry credentials come first. A registry push token lets an attacker replace an image you will deploy next week. Revoke the old credential at the issuer: deleting it from Railway does nothing, and creating a new key does not disable the old one.

3. Rotate AI provider keys. These were the stated target. If a vendor already revoked a key, issue a new one now. Otherwise create the replacement, set it in Railway, deploy, confirm traffic, then revoke the old key.

4. Change database credentials inside the database. A new DATABASE_URL value does not change the password the server accepts. Set a new password on the role, update the variable, and redeploy. Railway also asks you to remove public network access from databases: under the database service's Settings, Networking, remove the public TCP proxy if only other Railway services connect, and they can keep using the private *.railway.internal host.

5. Then the rest: Stripe and other payment keys, email and SMS sending keys, OAuth client secrets, session signing and encryption keys.

6. Redeploy and reconnect. Commits pushed while deployments were paused on October 21 were not deployed, so redeploy your latest commit. Reconnect GitHub, since Railway rolled the app installations, and create fresh Railway tokens for the CLI and for CI.

Checking for use of stolen keys

Railway's report gives no attacker IP addresses or other indicators, so the evidence is on the provider side.

• AI providers. On the OpenAI and Anthropic usage pages, filter by API key from October 20 onward. Distillation looks like high volume on your most expensive model, long outputs, steady traffic around the clock, or models your code never calls. Read usage before you delete a key.
• GitHub. Review all app access. Your personal security log is at Settings, Security log; for an organization, Settings, Audit log. Look for new deploy keys, personal access tokens, OAuth authorizations and webhooks you did not create.
• Registries. Railway names Docker Hub audit logs. Look for pushes and new tags you did not make, and compare running image digests against what your CI built.
• Cloud. In AWS CloudTrail or the Google Cloud audit logs, search for calls made with the old access key ID from October 20.
• Databases. Check connection logs for sources outside Railway's network and for new roles.

Export what you find now, before log retention runs out.

Secrets a platform should not hold

Every static secret in a hosting platform's variables is readable by that platform's build system, which is the part attackers keep going after. Registry pushes and cloud deploys from GitHub Actions can use OpenID Connect (OIDC) instead, where the job exchanges a signed identity token for short-lived credentials and nothing long-lived sits in Railway.

AI provider keys cannot be made short-lived today, so cap them instead. Issue one key per service and per environment, put it in its own provider project or workspace with a monthly spend limit, and restrict it to the models that service uses. A stolen key is then a bounded bill, and the usage logs name the service that leaked it.

Keep an inventory of which platform holds which credential, so the next rotation starts from a list.

Our cloud and Kubernetes security team reviews where deployment platforms and pipelines hold secrets, and our security operations team watches provider and audit logs for this kind of misuse. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Railway security disclosure, October 21, Railway preliminary report, Railway variables documentation, The Hacker News, RuntimeWire, Hoodline, TokenPost, Safeguard.