Railway warned on October 21, 2026 that customer secrets may have been exposed. In its security disclosure, Railway says an unauthorized party may have accessed stored environment variables and obtained some decrypted contents. Those variables can hold API keys, database passwords and private registry credentials.
The company recommends that every user rotate stored secrets, including API keys and private registry credentials. Railway's initial investigation suggests only a subset of users may be affected, but it hasn't established the full scope. Its advice applies to all users while that review continues.
The response has an operational obstacle. At 01:22 UTC on October 22, Railway's status page still said users could not complete redeployments while builds were unavailable. That leaves developers able to cut off a credential at its provider before their Railway service can start using its replacement. Revoking access can therefore interrupt an application that still depends on the old secret.
Revocation can start while deployments are blocked
Railway's AWS guide tells customers to deactivate potentially exposed access keys and review CloudTrail and billing for unfamiliar activity. It also directs users to search CloudTrail event history in every Region. A resource created in a Region an application doesn't use can otherwise escape a routine check of its usual infrastructure.
Replacing the credentials in a running service takes another step. For Google Cloud, Railway says replacing a service-account key stored in a variable requires editing that variable and redeploying. Its instructions also call for checking that the new deployment is active and making successful Google API calls. Saving a replacement value in the dashboard doesn't complete that process.
Railway has separately begun rotating its own storage-bucket credentials. Its incident updates say new credentials will appear automatically in the dashboard, but services need redeployment to pick them up. Users therefore have two dependencies to track: the provider-side validity of each secret and whether the application has actually loaded its replacement.
A replacement key still needs an access review
Google's compromised-credentials documentation explains another limit to key rotation. Google says service-account access tokens remain valid until they expire. Blocking an already issued token requires disabling or deleting the service account, or applying an IAM deny policy. Disabling the account also removes access from legitimate workloads that use it. Teams responding to a suspected exposure need to consider those active tokens alongside the persistent key file.
Railway's Google Cloud checklist also calls for reviewing audit logs and checking for unfamiliar accounts, keys and permission changes. That review answers a different question from whether the replacement works: what access the old credential may already have enabled.
Watch Railway's incident page for confirmed build restoration so replacement credentials can reach running services. The company also says it will contact affected customers as it confirms which accounts were involved. Those notices should narrow the exposure assessment; a successful redeployment alone cannot establish whether a secret was previously used without permission.