For: developers and operators who run apps or databases on Railway, the application hosting platform (PaaS), especially those who keep AI API keys, payments, GitHub, cloud or database credentials in environment variables.
This article is based on Railway's official blog posts (its disclosure, preliminary report and user guides) and its status page. It does not cover attack techniques, which the company has not disclosed either.
Developing: this article will be updated as the organisation publishes more
As of 11:00 UTC, October 24, 2026 (20:00 JST)Not yet known
- Which environment variables were decrypted (the company says it cannot identify them)
- Whether source code was accessed (to be confirmed in the final report)
- Details of the attack
- Whether exposed keys have been used
The company's preliminary report is dated October 22; according to the status page, it was made available at 16:38 UTC on October 23. The company says the investigation is ongoing and that it will publish a follow-up when the investigation concludes. No date is given for the final report.
The status page marked the incident resolved at 22:06 UTC on October 23; builds and deployments are operating normally. New signups remain paused.
What Railway users should do today
Steps 1 and 2 apply to every user. The company says the impact may be limited, but recommends these actions to all users as a precaution.
Rotate secrets: reissue at the source and revoke the old values
The company asks you to revoke and reapply every sensitive environment variable stored on Railway before October 21. That includes API keys and private registry credentials.
Work in this order:
- List your environment variables. Open each service's Variables tab and mark the secret values (API keys, tokens, passwords, signing keys, connection strings)
- Issue new values in the dashboard of each source: the AI API, payments provider, GitHub, cloud, external databases and so on
- Update the Railway variables and redeploy the services. Containers read variables only at startup, so they keep running with the old values until you redeploy (company guide)
- Once the new values work, revoke or delete the old values at the source
Changing the value only inside Railway leaves the exposed value usable until you revoke it at the source (this site's note).
If you rotated before 03:32 UTC on October 22
In its October 21 disclosure, the company asked users to rotate all environment variables immediately. It later said it confirmed at 03:32 UTC on October 22 that the attacker no longer had access to its systems. The preliminary report explains that it wanted the attacker ejected before telling users to rotate, so that new credentials would not be compromised again right away. Secrets rotated before 03:32 UTC on October 22 are therefore safer rotated once more (this site's note). The status page says that this update alone does not require repeating rotations already completed since the incident was contained.
Databases: regenerate passwords and remove public access
The company advises all users to remove public network access to databases. Its guide says that a database with public access (the TCP proxy) enabled can be reached with its credentials from anywhere on the internet until you rotate.
- For PostgreSQL, MySQL, Redis and MongoDB, use Regenerate in the database view. It changes the password inside the database and the variables in one step, and drops open sessions (company guide)
- Do not edit password variables such as POSTGRES_PASSWORD by hand or change the password directly in the database. The variable and the database fall out of sync (company guide)
- Redeploy every service that references the variables (for example
${{ Postgres.DATABASE_URL }}). Replace pasted connection strings with references - Under Settings, Networking, turn off Public Access if nothing outside the project needs it. Anything outside (local development, CI, BI tools) needs the new
DATABASE_PUBLIC_URLpasted in by hand
GitHub and registries: review audit logs and connected apps
The company recommends checking GitHub audit logs and app access, and the audit logs of registries such as Docker Hub. Its guide lists these checks:
- Personal account: the GitHub security log (90 days), authorized OAuth apps and GitHub Apps, SSH and GPG keys, and personal access tokens. Revoke anything you do not recognize and regenerate tokens
- Organization: the organization audit log (180 days). Export the log before revoking anything. For each repository, review deploy keys, secrets, webhooks and collaborators
- GitHub Container Registry (ghcr.io): Railway removed the GitHub tokens it stored, but those tokens still work on GitHub until revoked. Delete the old token on GitHub, create a new one with the read:packages scope and set it on each service
The guide also warns that an attacker with push access can add a webhook or secret that outlives a password reset.
AI APIs and payments: look for usage and charges you did not make
According to the company's preliminary report, the attacker appears to have been seeking AI provider API keys. The company has published usage-check guides for OpenAI, Anthropic, OpenRouter, Grok, Stripe, AWS and GCP. The OpenAI guide, for example, says to:
- Delete the possibly exposed key and create a new one in the same project
- Open usage, group by API key, and compare token volume, request counts and model mix in the exposure window with your normal traffic
- Check billing for spend in the period and any credit grants consumed
- Review members and project membership for people you did not invite
- Keep the usage details and contact the provider's support if you find misuse
Check at least from the start of the attack window (13:58 UTC on October 20) until you rotated the key (this site's note).
Inside Railway: log in again, recreate tokens and redeploy
During its response the company revoked all login sessions, Railway access tokens, GitHub connections and storage bucket credentials. Commits pushed while deployments were paused were not deployed.
- Log in with the same Gmail, GitHub account or email you signed up with. Logging in with a different identity creates a new, empty account (company guide)
- Reconnect GitHub in account settings, reconnect the repository in the service's Settings, and deploy the latest commit
- CLI: run
railway logout, thenrailway login. CI: recreate the project token (RAILWAY_TOKEN) or account/workspace token (RAILWAY_API_TOKEN) and replace it in your CI secrets - Redeploy services that use buckets so they pick up the new credentials. Also check buckets for files you did not upload or deletions you did not make (buckets have no automatic backups, the company says)
- In the workspace audit log, look for variable reads, registry credential changes and deployments in the exposure window that were not made by your team or by Railway (shown as "Railway Staff")
Secret stored on Railway before October 21
Treat as exposed, contacted or not
↓→
1. Issue a new value at the source
Update the variable and redeploy, then revoke the old value
Database with public access
Reachable from the internet with a leaked password
↓→
2. Regenerate the password and remove public access
Redeploy every service that references it
AI API, payments, GitHub
Keys the attacker appears to have sought
↓→
3. Check usage, charges and audit logs
From 13:58 UTC Oct 20 until you rotated
Be careful with messages claiming to be Railway support
The company says it will email affected customers directly. Its account recovery guide tells users not to send passwords, login codes, recovery codes, API tokens or secret values to support. If a message tied to this incident asks for secret values or login codes, assume it is not genuine (this site's note).
Revocation notices from GitHub, OpenAI and other providers follow Railway's request, and the company says they do not imply that your credentials were impacted. Do not click links in such messages; open each provider's dashboard directly.
What happened (per Railway)
The following is based on Railway's blog posts "Security Disclosure: Wednesday October 21st" (October 21, 2026) and "Preliminary Report: Oct 21st Security Incident" (dated October 22; made available at 16:38 UTC on October 23, per the status page), and on its status page. Times are UTC.
Oct 20, 13:58
Monitoring flags abnormal activity in the form of elevated latency; the on-call engineer begins investigating.Oct 20, 14:03–16:51
The activity is identified as an attempted privilege escalation by a hostile external party. Potential privilege escalation is found in the build infrastructure, and build pipelines are halted.Oct 20, 18:05–19:53
Mitigations are deployed and the exploit can no longer be reproduced. At 19:53, further evidence shows the attacker could escalate access at larger scale across multiple parts of the system in parallel.Oct 21, 04:24–05:23
Forensics finds the attacker had pulled secrets in encrypted form, without being able to decrypt them at that time.Oct 21, 05:27–07:25
The attacker obtains credentials for the CI environment and decrypts artifacts holding additional API access.Oct 21, 07:25–09:18
Database evidence shows an unauthorized query of encrypted environment variables; a subset was decrypted using a combination of compromised credentials.Oct 21, 09:25
Railway notifies providers about the surfaces the attacker accessed and asks them to revoke keys (the report's FAQ gives 09:35).Oct 21, 20:19–22:10
Railway announces user session invalidation and publishes its security disclosure and customer guidance.Oct 22, 03:32
Railway confirms the attacker no longer has access to any internal systems, and begins reinitializing internal systems with new credentials.Oct 22, 17:00–22:49
Full API restoration and normal deployments for all plans are reported.Oct 23, 16:38
The preliminary report dated October 22 is made available (status page).Oct 23, 18:57
Notifications to workspaces assessed as higher risk are completed (status page).Oct 23, 22:06
The status page marks the incident resolved. New signups remain paused.
- What happened
- An unauthorized third party accessed internal systems, obtained customers' encrypted environment variables and decrypted a subset of them
- Scale
- At most 1.85% of all workspaces (about 100,000 workspaces) had some environment variables potentially compromised. The query records alone cannot identify which specific variables were affected, because the keys were envelope encrypted (the key that encrypts the data is itself encrypted with another key), the company says
- Attacker's aim (company's assessment)
- To obtain AI provider API keys for model "distillation" (training another model on a model's outputs; this site's explanation). The company believes this is part of a series of attacks targeting platform companies with the aim of compromising AI inference providers
- Higher-risk environments
- Workspaces with a very large number of environment variables, and environments with many AI provider keys
- Stated as not accessed
- Railway user accounts were not logged into
- Not yet confirmed
- Access to source code has not been ruled out and will be confirmed in the final report
- Provider notifications
- Railway notified GitHub, GitLab, Anthropic, OpenAI, OpenRouter, Google, Stripe and others of potentially decrypted keys and asked them to revoke them. For some providers it supplied every key registered on the platform regardless of known impact. More than 100,000 users were affected by provider reset requests
- Service impact
- Running services stayed online. New builds and deployments, the dashboard, API, CLI and support were unavailable at times
- Company actions
- Shut down potentially compromised internal tooling; rolled all keys, and rolled them again after validating the intruder was removed; engaged an external forensics company; moved builders to single-tenant environments; rolled credentials for all storage buckets; rebuilt internal tooling from validated source; added a way to mass-revoke Railway application permissions
What is known and what is not
Status as of October 24, 2026. This table will be updated as the company publishes more.
| Item | What was disclosed | Status |
|---|---|---|
| Encrypted environment variables obtained | Obtained through an unauthorized query | Confirmed (company) |
| Decryption | A subset decrypted using a combination of compromised credentials | Confirmed (company) |
| Workspaces in scope | At most 1.85% of all workspaces (about 100,000) | Possible (company) |
| Which variables were decrypted | Cannot be identified from the query records alone | Under investigation |
| Private registry credentials | Listed for rotation | Possible (company) |
| User accounts | The attacker did not access Railway user accounts | Denied (company) |
| Source code | Access not ruled out; to be confirmed in the final report | Under investigation |
| Running services | Stayed online | Confirmed (company) |
| Attack window | 13:58 UTC Oct 20 to 03:32 UTC Oct 22 | Confirmed (company) |
| Attack details | Not disclosed, to protect customers | Under investigation |
| Misuse of exposed keys | Not stated | Not stated |
| Time providers were notified | 09:25 UTC in the report's timeline, 09:35 UTC in its FAQ | Inconsistent in the report |
How to read the figures: what the 100,000 counts
The "about 100,000" in the preliminary report is the number of workspaces (1.85% of all) that had some environment variables potentially compromised. The report says more than 100,000 users were affected by provider revocation requests, and that the customers it contacted as high risk exceed the 1.85%. Being contacted, or having a key revoked, does not confirm exposure. Conversely, the company says workspaces outside the higher-risk groups are not confirmed safe.
Why AI API keys are targeted
What follows is general and does not mean these things happened in this incident. The aim the company describes for this attacker is obtaining AI API keys for model distillation.
An AI API key is money and compute that anyone holding it can spend. When a stolen key is used heavily, the bill goes to its owner. When large volumes of output are collected under the owner's name, the provider may suspend the account for a policy violation such as its ban on distillation. How that works and how to appeal is covered in why an account gets banned after its API key is stolen.
A hosting platform holds many customers' keys in one place. That is likely why the company describes workspaces with many environment variables or many AI keys as higher risk. In the same month, the developer of LiteLLM also said the attacker in its incident was mainly looking for LLM provider keys (a separate incident; no link between the two has been disclosed). For the wider picture of attacks that use AI or target AI keys, see defending against AI-driven cyberattacks.
What Railway users should review: lessons from the disclosed facts
This section does not evaluate the company's response. It focuses on what users can do to be ready for the next incident, based on what was disclosed.
Assume platform-side encryption does not protect against a platform compromise
Railway's environment variables were encrypted, but according to the preliminary report the attacker decrypted a subset using a combination of compromised credentials. A hosting platform has to turn variables back into plain values to run your app, so once privileges inside the platform are taken, encryption alone cannot fully protect them (this site's note).
Alongside platform encryption, store secrets so that a leak does limited damage. As a first step, set spending limits and alerts with your AI API and payments providers. Separate keys for production, staging and development also shrink what you have to rotate. Storing secrets is covered in what's actually dangerous about .env and API keys.
Keep databases off the public internet
According to the company's guide, a database with public access enabled can be reached from anywhere on the internet with a leaked connection string. A database used only over the project's private network cannot be reached directly from outside even if its connection string leaks.
Outside access is usually needed only for local development, CI or BI tools. Even then, consider opening it only while needed, or using a separate read-only user (this site's note).
Share secrets through references so rotation happens in one place
The company's guide recommends sharing connection strings and keys through reference variables such as ${{ Postgres.DATABASE_URL }} rather than pasting them into each service. With references, changing the source value and redeploying reaches every service, and no pasted copy is forgotten.
In the same spirit, keep a running list of which secret each service uses and where it is reissued (this site's note). When you have to rotate everything, as now, that list decides how long the work takes. In a similar case, the Vercel security incident, what mattered was whether secrets were stored in a category whose values cannot be displayed later.
Limit GitHub connections to the repositories and scopes you need
In this incident the company revoked the GitHub tokens it held and recommends reviewing GitHub audit logs and app access. Limit the GitHub access you grant a hosting platform to the repositories it deploys, and give container registry tokens read access (read:packages) only, so a leak reaches less (this site's note). The problem of leaked credentials that stay valid is covered in leaked credentials that remain valid.
Sources (public record)
The facts in this article are based on the following public sources. Attack details are not reproduced.
- Railway, "Security Disclosure: Wednesday October 21st" (October 21, 2026; the status page posted "We have published a security notice" at 22:10 UTC on October 21) — blog.railway.com
- Railway, "Preliminary Report: Oct 21st Security Incident" (dated October 22, 2026; made available at 16:38 UTC on October 23, per the status page) — blog.railway.com
- Railway, "Railway Platform Outage" (status page, checked through the "Resolved" update at 22:06 UTC on October 23) — status.railway.com
- Railway user guides (October 22–23, 2026): "Rotate PostgreSQL Database Credentials" blog.railway.com / "Check for Anomalous GitHub Access" blog.railway.com / "Check for Unexpected OpenAI Usage" blog.railway.com / "Redeploy Buckets and Reconnect GitHub After the Credential Reset" blog.railway.com / "Recover Failing Deploys" blog.railway.com / "Resolving Login Issues" blog.railway.com
- Guides for other services (MySQL, Redis, MongoDB, Anthropic, OpenRouter, Grok, Stripe, AWS, GCP) are listed on the company's engineering blog — blog.railway.com
Update history
2026-10-24: First version, based on Railway's disclosure (October 21), preliminary report (October 22) and status page (through the 22:06 UTC update on October 23). Corrected the same day after checking the sources: the preliminary report's publication time now follows the status page (16:38 UTC, October 23), and the status of user account access is now "Denied (company)". The scope of decryption and whether source code was accessed will be added when the final report is published.
Read next
- Similar incidents: what developers should do after the Vercel security incident / the LiteLLM 1.107.0 compromise
- Why AI keys are targeted: defending against AI-driven cyberattacks / stolen API keys and account bans
- Storing secrets: what's actually dangerous about .env and API keys / API keys leaked from AI-written code
- Other 2026 incidents: list of data breaches and cyberattacks