Railway Security Incident: Exposed Environment Variables and What to Do Now

If you deploy apps on Railway, today is the day to stop what you are doing. On October 21, 2026, Railway, the deployment platform used by more than 2 million developers, disclosed a security incident that hits the exact place where you keep API keys, database passwords and tokens: its environment variable store.

According to Railway's official disclosure, an unauthorized third party may have accessed customers' encrypted environment variables and, for some of them, obtained the decrypted contents. Railway believes the attack is part of a series targeting platform companies with the aim of stealing keys for AI inference providers.

This post covers what happened, the timeline, what Railway has confirmed and what it has not, how the developer community reacted, and a concrete checklist for rotating secrets and checking for abuse today.

What Was the Railway Security Incident on October 21, 2026?

On the morning of October 21, Railway detected anomalous activity in the systems that store customer environment variables. That store holds the most sensitive data an app has: OpenAI, Anthropic and Stripe API keys, database credentials, AWS and GCP keys, and private registry credentials.

Railway found the incident through its own detection; no outside researcher or bug bounty report is credited. To contain it, Railway froze all builds and deployments in every region, logged every user out, and invalidated a wide range of platform-managed credentials.

What Railway has not said matters just as much. As of October 23, the company has not named a root cause, intrusion method, attacker, start of access or number of affected customers. It says the impact may be limited to a subset of users, who will receive an email, and has promised a formal postmortem.

How Did the Incident Unfold?

According to Railway's status page, the key milestones (UTC, accurate to within about one status update across sources) were:

• October 21, 07:24: the incident opened as a platform outage.
• October 21, 09:28: the dashboard, API and CLI went down and builds paused in every region.
• October 21, 20:30: Railway invalidated OAuth sessions, forcing every user to log in again.
• October 21, around 22:00: the security notice went up, asking customers to rotate all environment variables.
• October 21, 22:37: bucket credentials started regenerating across all environments.
• October 22, around 04:17 to 04:39: all Railway API tokens were invalidated.
• October 22: builds came back by plan tier, Enterprise first, then Pro, Hobby and finally Free and Trial.

The gap between the incident appearing and the security warning was about 14.5 hours. That gap drew more criticism than anything else.

What Has Been Confirmed, and What Has Not?

With an investigation still open, it helps to separate official statements from third-party claims. Railway has confirmed three things: encrypted environment variables were accessed, some were decrypted, and in Railway's assessment the target was AI provider keys.

The following come from third parties and have not been confirmed by Railway:

• A blockchain researcher estimated about US$371,000 in crypto drained across 19 chains starting at 19:36 UTC on October 21, roughly two and a half hours before the public notice.
• Several users on Hacker News reported abuse of their OpenAI and Anthropic keys and S3 buckets.
• The founder of Postiz said they received compromise alerts from Anthropic and Stripe.

Railway has not said that data inside customer databases, source code or build artifacts was accessed. It also has not clarified whether sealed variables, which are never shown in the UI or API, were in scope.

Why Are Attackers Going After AI API Keys?

AI keys are valuable because they can be resold immediately or used to run models at scale on someone else's bill. Railway was not the only case that week. OpenCode, an AI coding tool, said it was breached and that some customers' OpenAI, Anthropic and Google keys were exposed. On October 21, a malicious release of the LiteLLM library appeared on PyPI and Docker for about two hours, carrying code built to steal cloud and AI tool credentials, according to Datadog Security Labs.

No source confirms a single group is behind these incidents. What they share is motive: PaaS environment variable stores have become concentrated targets where an attacker can collect keys for many apps at once. Earlier, in April 2026, Vercel also exposed environment variables that were not marked as sensitive.

The incident landed on the same day PHP patched the critical PHP2Shell vulnerabilities, but there is no evidence the two are related. Railway did not mention PHP or any CVE.

How Did the Developer Community React?

The reaction was mostly negative. The disclosure reached 564 points and 325 comments on Hacker News, and a daily.dev summary of 185 comments across Hacker News, Lobsters and X rated 69 percent skeptical and only 5 percent positive. The three main complaints:

• Slow notice: some users said they saw signs of abuse hours before Railway spoke up.
• An operational catch: Railway asked customers to rotate secrets while deployments were blocked, so the new values could not reach running apps.
• Missing detail: nothing on how the attacker got in or how wide the impact was.

A Railway employee explained on Hacker News that the company did not want to recommend rotating keys before it could confirm the hole was closed, and apologized. Security firms such as GitGuardian agreed with the advice itself: treat every Railway environment variable as exposed.

What Should Railway Customers Do Right Now?

Railway asks every customer to rotate all environment variables, even if they are not sure they were affected. Not getting an email from Railway does not mean you are safe. Here is a checklist in order of priority:

• Rotate AI keys first: revoke and reissue OpenAI, Anthropic, OpenRouter and Grok keys. Check usage pages and billing for unfamiliar calls, and set spending limits.
• Rotate cloud keys: issue new AWS keys and GCP service account keys, disable the old ones, then search CloudTrail or Cloud Audit Logs for unusual activity such as new instances or new users.
• Rotate payment and database credentials: rotate Stripe keys and review transactions. For Railway-managed Postgres, use the Regenerate button rather than editing variables by hand, and turn off Public Access if you do not need it.
• Clean up GitHub: reconnect GitHub in Account Settings. GitHub tokens used as registry credentials were removed from Railway but still work on GitHub until you revoke them yourself.
• Recreate Railway tokens: every API token and project token created before the incident is invalid, so issue new ones for CI and scripts.
• Redeploy: containers only read variables at startup, so new values take effect only after a deploy. Services that use buckets must be redeployed too.
• Rotate internal secrets: JWT secrets, session secrets and encryption keys are in scope as well. Plan ahead, since rotating the JWT secret logs users out.

For each secret, the safe sequence is: create the new key at the provider, update the variable on Railway, deploy and verify, then disable the old key. If you already see signs of abuse, revoke the old key immediately and accept a short outage. Railway has published dedicated guides for each type of credential.

How Can You Check Whether Your App Was Abused?

Do not rely on Railway's audit log alone. The secrets were taken from Railway's store, not from your app, so the audit log may show nothing unusual. On top of that, Railway's audit logs are kept for only 48 hours on Free, Trial and Hobby, 30 days on Pro and 18 months on Enterprise. If you are on Pro, export yours now.

The more reliable signals live at your providers: usage and billing pages at OpenAI, Anthropic, AWS, GCP and Stripe, your GitHub security log, and unfamiliar connections to your database. Entries marked Railway Staff in the audit log are Railway's own credential resets and are expected.

Long-Term Lessons for Running Apps on a PaaS

The Railway incident shows that attackers do not need to break into each app when they can go straight to the place where millions of apps keep their secrets. You cannot control a platform's security, but you can limit the damage when it fails:

• Set hard spending caps on every AI and cloud account; it is the cheapest way to contain damage when detection is slow.
• Split keys by environment and by service, so one leaked key does not unlock everything.
• Use narrowly scoped project tokens in CI instead of account tokens.
• Mark sensitive variables as sealed, use private networking and turn off public access to databases.
• Prefer short-lived credentials, and keep an incident runbook that records which secret lives where, who rotates it and how.

If you need a review of how your app stores secrets or a plan for rotating keys safely after this incident, Growthtrait's website development team can help. Contact us to get started.