Between October 20 and 22, 2026, attackers broke into internal systems at Railway, the app hosting platform, and pulled customer environment variables. Some of those secrets were decrypted. Railway says the attacker was hunting for AI provider API keys. If you deploy on Railway, or on any platform that stores your secrets for you, this is worth reading closely.

Key takeaways

• Attack window: October 20, 13:58 UTC to October 22, 03:32 UTC, per Railway’s preliminary report.
• The attacker escalated privileges in build infrastructure, reached CI credentials, then queried and partly decrypted stored environment variables.
• At most 1.85% of workspaces, about 100,000, had env vars potentially compromised.
• Railway says the goal was AI and platform API keys for model “distillation.”
• Railway accounts weren’t logged into. Running apps stayed up. Builds were paused.
• Railway recommends anyone who signed up before October 21 rotate every sensitive variable.

What happened at Railway?

An outside attacker escalated privileges inside Railway’s build infrastructure, moved into internal systems, got credentials for the CI environment, and queried encrypted customer environment variables. Some were decrypted. Railway disclosed it on October 21, 2026, and published a preliminary report on October 22 with a detailed timeline.

The first public notice was the Security Disclosure of October 21. It said an unauthorized party “may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents.” Railway told all users to roll their env vars and private registry credentials.

The fuller account is the Preliminary Report. Railway says it brought in outside incident response experts and the authorities, and that forensics is still going on.

TechCrunch covered the story on October 22 and noted that Railway hadn’t named a root cause and planned a post-mortem.

What was the timeline of the Railway attack?

Railway’s own timeline runs from a latency alert at 13:58 UTC on October 20 to confirmation at 03:32 UTC on October 22 that the attacker had no remaining access. In between, the team thought it had fixed the hole, then found the attacker could escalate further, and halted builds twice.

Here’s a condensed version of Railway’s table. Times are UTC, with IST in brackets where useful.

When (UTC)	What happened
Oct 20, 13:58 (19:28 IST)	Monitoring pages on-call for abnormal latency
Oct 20, 14:03 to 16:51	Identified as privilege escalation in build infrastructure. Build pipelines halted
Oct 20, 17:03	Incident declared on the status page
Oct 20, 18:05 to 19:53	Exploit reported remediated and no longer reproducible
Oct 20, 19:53	New evidence the attacker could escalate at larger scale, in parallel
Oct 21, 00:22 to 03:08	More access routes found. Builds halted again
Oct 21, 04:24 to 05:23	Attacker found pulling secrets, still encrypted at that point
Oct 21, 05:27 to 07:25	Attacker reaches CI credentials and decrypts artifacts holding more API access
Oct 21, 07:25 to 09:18	Database evidence of a query on encrypted env vars, some decrypted
Oct 21, 09:25 (14:55 IST)	Vendors notified and asked to revoke keys
Oct 21, 20:19 to 22:10	Sessions invalidated, public disclosure, rotation guidance
Oct 22, 03:32 (09:02 IST)	Railway confirms attacker has no access to internal systems
Oct 22, 17:00 to 22:49	Full API restoration and normal deploys on all tiers

The part that stands out to me is 19:53 on October 20. The team had validated the fix. Then it found the attacker had more reach than it looked. That’s how these things usually go, and it’s why Railway kept builds off for so long.

How did the attacker get in?

Railway hasn’t published the exact entry point yet. What it has said is that the attacker escalated privileges in build infrastructure, then reached CI credentials that let it decrypt artifacts with more API access, and combined compromised credentials to decrypt a subset of stored env vars.

So the chain, as far as it’s public, looks like this:

1. Privilege escalation inside the shared build system.
2. Wider movement across internal systems.
3. Access to CI credentials.
4. Decryption of CI artifacts holding more API access.
5. A database query against encrypted environment variables, with some decrypted using the stolen credentials.

Railway says the attacker “had access to abliterated models and substantial compute resources” which helped it run “highly sophisticated exploits.” An abliterated model is an AI model with its safety refusals stripped out. Railway didn’t explain how the models were used, and says it’s holding back exploit details while the investigation runs. I’d treat the specifics as unconfirmed until the final report.

One technical note from the report matters for anyone thinking about encryption. Railway envelope-encrypts the keys. Because of that, the database query alone couldn’t tell Railway which specific variables were decrypted. Encryption limited the damage, but it also made scoping harder.

What did the attacker want?

Railway says the attacker was after AI provider and platform API keys to run “distillation attacks.” In plain terms, stolen model API keys let someone query a model at huge volume on someone else’s bill, and use the answers to train their own model. Railway’s logs showed the specific key names the attacker searched for.

TechCrunch reported that Railway linked the breach to a wider campaign against platforms “with the aim of compromising AI inference providers.” It also noted that, earlier that week, AI coding tool OpenCode said hackers took more than 1% of its customers’ API keys and other secrets in what it called a similar distillation attack. I haven’t independently checked OpenCode’s statement, so I’m citing TechCrunch’s reporting of it.

Railway says the highest-risk accounts were workspaces with lots of env vars and environments holding many AI vendor keys.

How many users were affected?

Railway says at most 1.85% of all workspaces had environment variables potentially compromised, which it puts at about 100,000 workspaces. It asked upstream vendors to revoke keys across a far wider set, so many more people got revocation emails than were actually exposed.

That last bit confuses people, so it’s worth being clear. Railway sent providers including GitHub, GitLab, Anthropic, OpenAI, OpenRouter, SpaceXSI and Stripe the keys it believed might be decrypted. For some vendors, like GitHub and SpaceXSI, it sent every key on the platform. Railway says getting a revocation email “does not imply that their credentials were impacted.”

What wasn’t hit, per Railway: user accounts weren’t logged into, and running deployments stayed online. Railway hasn’t ruled out access to user source code and says it’ll confirm in the final report.

What should Railway users do right now?

Rotate every sensitive environment variable you stored on Railway before October 21, 2026, revoke the old values at the provider, and redeploy. Then check GitHub audit logs, app access, and registry logs like Docker Hub. Railway also advises removing public network access from databases.

A practical order to do it in:

• Database credentials first. Change the password in the database, update the variable, redeploy. If the database has a public endpoint, turn it off and use private networking.
• AI keys next. OpenAI, Anthropic, OpenRouter and the like. Check usage dashboards for spikes since October 20. Those are exactly what the attacker wanted.
• Payment and cloud keys. Stripe secret keys, AWS or GCP credentials, storage buckets. Railway says it rolled credentials for storage buckets deployed on Railway.
• GitHub. Railway rolled all its GitHub App installations. Review the security log and authorized apps on your account and org.
• Registries. Rotate Docker Hub or private registry tokens and check pull history.
• Fix failing deploys. Railway revoked its own access tokens, so deploys from your laptop or CI fail until you create new tokens (Railway guide).

Rotating means making a new key and killing the old one. Making a new key while the old one still works doesn’t help.

What did Railway change after the breach?

Railway says it shut down possibly compromised internal tools, rolled all keys twice, hired an outside forensics firm, rebuilt infrastructure tooling from validated source, and moved its builders from isolated multi-tenant machines to single-tenant ones. It also added a way to mass-revoke Railway app permissions when something looks wrong.

The builder change is the interesting one. Railway says it went from its “third generation isolated multi-tenant” builders to “fourth generation single-tenant environments,” a rollout that was planned for the following week and pushed forward. Since the attack started with escalation in build infrastructure, giving each build its own environment shrinks how far one escape can reach.

What can web developers learn from the Railway breach?

Your secrets are only as safe as the platform holding them, so plan for the day they leak. Use scoped or short-lived keys, set spending limits on AI APIs, keep databases off the public internet, and know how to rotate everything in an hour. Most of us can’t do that last one yet, and incidents like this show it.

Here’s what I’m changing in my own setups:

• Scope every key. A Stripe restricted key that can only create checkout sessions does far less harm than a full secret key.
• Cap AI spend. Set hard monthly limits on model provider accounts. A stolen key with a cap is an annoyance, not a disaster.
• Prefer short-lived credentials. OIDC federation from your CI to AWS or GCP means there’s no long-lived cloud key sitting in env vars at all.
• Private databases by default. If the database has no public endpoint, a leaked password alone isn’t enough.
• Keep a rotation runbook. A simple list of every secret, where it lives and how to rotate it.
• Turn on alerts. Usage alerts on AI providers and billing alerts on cloud accounts catch abuse fast.

If you’re building on Next.js or Node and want more on handling config safely, my backend and security posts cover it, and the Zod validation guide shows how to type-check env vars at startup.

Is Railway safe to use now?

Railway says yes. It reports that impacted systems were redeployed and revalidated, and builds on all tiers were restored on October 22. Its forensic investigation is still running, with a final report promised. Whether to stay is your call, but rotating your secrets isn’t optional either way.

I’d wait for the final report before drawing firm conclusions about root cause. The preliminary report is detailed on timeline but thin on the actual exploit, and Railway says that’s deliberate for now.

FAQ

When did the Railway breach happen?

Railway puts the attack window at October 20, 2026, 13:58 UTC through October 22, 03:32 UTC. It disclosed publicly on October 21 and published a preliminary report on October 22.

Were Railway user accounts hacked?

No, per Railway. Individual accounts weren’t logged into. The attacker accessed internal systems and decrypted env vars for a subset of workspaces. Railway still revoked all its access tokens as a precaution.

How many Railway workspaces were affected?

At most 1.85% of workspaces, about 100,000, had env vars potentially compromised. Railway contacted those customers and others it rated high risk.

Why did GitHub or OpenAI revoke my key?

Railway sent possibly decrypted keys to vendors and asked them to revoke. Some vendors got every key Railway held. A revocation email doesn’t mean your key was actually stolen.

Did my Railway app go offline?

No. Running services stayed up. New builds and deploys were paused during the incident and were restored on all tiers by October 22.

What should I rotate first?

Database passwords, AI provider keys, payment keys and cloud credentials, then GitHub and registry tokens. Revoke old values, redeploy, and check provider usage since October 20.

What was the root cause?

Railway hasn’t published it yet. It confirmed privilege escalation in build infrastructure and access to CI credentials, and says it’ll share more in its final forensic report.