VULNpocalypse
HighBreach / campaignMonitoring

Railway breach: rotate all environment variables and secrets

Railway confirmed attackers may have decrypted customer environment variables; rotate every secret stored there and review provider logs.

Published
Updated
Exploitation
Yes, Railway confirmed unauthorized access and BleepingComputer reports about $740,000 in fraudulent AI usage from stolen credentials

What happened

Railway disclosed anomalous activity on the systems that store customer environment variables. GitGuardian dates the disclosure to Oct. 21, 2026, and GBHackers does the same. BleepingComputer gives October 22, and TechCrunch refers to a Railway blog post on Wednesday. Railway said the third party “may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents”, according to TechCrunch.

Initial notice. Per GBHackers, the first notice did not name an attacker, give an affected account count or explain the entry method. Railway paused deployments while it contained the incident. GBHackers says builds were still unavailable at 02:19 UTC on October 22, returned across all plans that day, and that the outage was marked resolved on October 23.

Follow-up report. According to BleepingComputer, Railway published a fuller incident report on November 10. StepSecurity summarises the same report. We did not receive Railway’s own posts, so the details below come from these outlets.

  • Timeline and entry point: The attack began on October 20. BleepingComputer says attackers exploited a previously unknown vulnerability in Railway’s build infrastructure to escape filesystem isolation and obtain an internal credential. StepSecurity describes a partial escape that let the attacker read files on the host VM.
  • Internal access: The credential gave access to stored build histories and a copy of Railway’s internal source code, per BleepingComputer.
  • Second flaw: A second issue, an improperly configured trust relationship, led to credentials used to decrypt customer environment variables. StepSecurity identifies it as an OIDC configuration error.
  • Scope: At most 1.85% of workspaces, about 100,000, could have had variables decrypted. Both BleepingComputer and StepSecurity call this an upper bound, not a confirmed count of stolen secrets.
  • Linked-account tokens: BleepingComputer reports that linked-account tokens for 1,852 users were also exposed, including GitHub OAuth tokens and AI agent keys. Railway reset them and notified those users.
  • Attacker focus and cost: Railway’s investigation found the attackers specifically searched for AI provider credentials, though some queries targeted cloud, database and payment credentials (BleepingComputer). BleepingComputer reports about $740,000 in unauthorized AI usage from the stolen credentials. Railway is working with providers to reimburse customers and says it will cover charges providers decline to refund.
  • Containment: Railway says the attackers were fully removed on October 21 and that the exploited vulnerabilities have been remediated (BleepingComputer).
  • What was not found: Railway found no evidence that customer Git repositories were downloaded or customer databases accessed (BleepingComputer).
  • Wider campaign: Railway links the incident to attacks on platform companies aimed at compromising AI inference providers. BleepingComputer says security firm Wiz calls this wave “Black October” and lists Northflank, OpenCode, Warp and Lightning AI among other targets. Railway has not confirmed who the attacker is, and TechCrunch notes the root cause was not stated in the initial disclosure.

Am I affected?

Treat yourself as potentially affected if you stored any secrets as Railway environment variables. That includes API keys, database passwords, cloud credentials and private registry credentials.

  • Railway told all customers to rotate, even though it believes the impact is limited to a subset of users (TechCrunch, GitGuardian).
  • Affected customers are to be contacted by email (GitGuardian). GBHackers reports that by October 23 Railway had notified workspaces it identified as higher risk, and warned that workspaces not notified had not been confirmed safe.
  • GitGuardian notes that sealed variables cannot be read back from the UI, API or CLI, but the disclosure does not say whether they were in scope. Rotate them too.
  • If you used Railway’s GitHub login or linked AI agent keys, note the 1,852 reset tokens reported by BleepingComputer. Whether your account was one of them is not confirmed in the sources unless Railway notified you.

What to do now

  1. Inventory every service and environment in Railway and list the secrets in each. GitGuardian describes dumping each service’s variables with the Railway CLI into a local file and scanning it with ggshield (ggshield secret scan path) to see which values are still valid secrets. Delete the dump files afterwards.
  2. Rotate secrets in the upstream service first (for example AWS, GCP, GitHub or AI providers), then update the values in Railway, as GitGuardian advises. Railway published guides for AWS, GCP and GitHub. GBHackers adds guides for PostgreSQL, MongoDB, Redis, MySQL, AI providers and Stripe.
  3. Rotate private registry credentials, revoke the old values, redeploy dependent services and verify they work (Railway guidance as relayed by GitGuardian and GBHackers).
  4. Replace any Railway Public API tokens. GBHackers reports Railway invalidated existing API tokens, and that storage bucket credentials were rotated with replacements appearing in customer dashboards.
  5. Review logs and billing at each connected provider for unusual activity, especially AI provider usage, given the $740,000 in fraudulent charges BleepingComputer reports.
  6. If you finished rotating after containment, GBHackers says Railway did not require you to repeat it solely because of the October 23 update. Reviewing provider activity is still advisable.
  7. For your own pipelines, StepSecurity suggests reviewing what a compromised build job could reach, keeping production credentials out of jobs that do not need them, and checking OIDC trust conditions. This is that vendor’s guidance, not a Railway requirement.

Sources