Security response · October 2026
Railway security incident credential rotation checklist
When a website and worker share a key, both need its replacement. Map each credential to its issuer and consumers so the response can be checked service by service.
Incident guidance can change. Use the linked vendor notices for current scope and instructions.
Quick answer
For Railway's 21 October credential disclosure, track three separate outcomes: revocation at the credential issuer, replacement in every consumer, and review of downstream activity. A successful deployment establishes none of the other outcomes by itself. Start with a credential identifier and owner, then record evidence for each step.
What did Railway disclose
On 21 October 2026, Railway reported possible unauthorized access to encrypted customer environment variables and some decrypted contents. Its initial analysis suggested a subset of users, while its precautionary rotation recommendation applied to all users, including private registry credentials. Account scope remained under investigation. Railway's original disclosure.
This distinction matters when talking to customers: a precautionary response is not confirmation that a particular customer's database was accessed. Keep account-specific notices and your own activity review separate from the general incident announcement.
What Railway and the application owner each control
| Control | First place to obtain evidence | App team's next action |
|---|---|---|
| Scope of the provider incident | Railway's disclosure and account-specific notices | Preserve the notice and identify the services in that account |
| Validity of an API or registry credential | The credential issuer | Revoke or rotate the affected authority |
| Use of replacement values | Each deployed consumer | Update, deploy, and verify the intended operation |
| Activity under the old identity | Downstream provider and application logs | Review the available history and record logging gaps |
This is a responsibility map for the response. It does not assign incident cause or establish which customer records were accessed.
Which credentials should you inventory
Use a credential map to identify the issuer, owner, and every consumer. Do not copy actual values into the worksheet or a support conversation.
| Credential category | Issuer or owner to contact | Consumers to check |
|---|---|---|
| AI provider API key | The model provider account owner | API service, workers, evaluation jobs, development tools |
| Database login | Database administrator | Web app, queues, migration jobs, scheduled tasks, BI tools |
| Private registry credential | Registry administrator | Deployment service, CI, image mirroring |
| Object storage credential | Storage account owner | Upload API, media workers, backup jobs |
| Payment or email service secret | Provider account owner | API, webhook handling, scheduled jobs |
| Signing or session secret | Application owner | Every verifier and issuer; session invalidation may require an application-specific plan |
These are inventory prompts. A row does not establish that its category was exposed in your account. Use Railway's account notice and your own service configuration to decide which credentials require action.
How do you complete a rotation
For each potentially exposed credential:
- Record an identifier and the current consumers. Use a key ID, role name, or masked reference. Include external consumers, staging, and one-off maintenance jobs.
- Contain the old authority at its issuer. Follow the provider's incident procedure to revoke the key or change the actual account credential. Replacing a string in Railway does not revoke a key at another provider.
- Issue a replacement through a trusted administrative session. Limit its permissions to the service's needs. Keep an emergency response separate from a later redesign of every integration.
- Update and deploy each consumer. Record the deployment ID and time. Do not assume a web deployment also replaced a worker, preview environment, or external cron job.
- Verify both sides. Check the intended operation with the new credential and confirm revocation of the old one using the issuer's status or a controlled, non-mutating check where supported.
- Review use of the old identity. Keep the result and the limits of the available logs.
This worksheet makes the secret lifecycle operational; OWASP covers rotation, revocation, access control, and auditing.
Three changes that can leave the response unfinished
| Change made | Remaining failure | How to close it |
|---|---|---|
| A new value was saved in Railway | The old key can remain valid at its issuer | Keep revocation evidence from the issuer |
| The web service was redeployed | A worker or external scheduled job can still use the old value | Verify every named consumer |
| The app works with the new key | Historical misuse remains unreviewed | Record the downstream activity review separately |
What is different for Railway PostgreSQL
For Railway's PostgreSQL template, use the supported Regenerate control in the database view. Railway says this updates the database password and associated variables together and restarts the database. Redeploy dependent services afterward. Reference variables and manually pasted connection strings require different follow-up. Its incident guide warns against changing only the variable or only the database password. Railway PostgreSQL rotation guide.
Keep a list of consumers that could not yet restart. If deployment availability blocks your response, follow the current Railway status updates and coordinate containment with the affected credential's issuer. Do not leave a suspect credential valid merely to avoid a temporary integration failure.
What activity should you review
Compare activity by credential or project against the service's normal use, including unexpected spend, unfamiliar models or regions, account membership changes, and new privileged identities where the provider exposes those records.
For OpenAI integrations, Railway's guide directs users to revoke potentially exposed keys, redeploy with replacements, and review usage and account changes. Preserve relevant usage details before contacting provider support. Railway's OpenAI response guide.
Railway also published AWS response guidance covering access-key deactivation, replacement, CloudTrail review across Regions, and billing checks. Its Google Cloud guidance covers service-account keys, audit logs, and already-issued tokens that can remain valid after a key is disabled. Have the cloud administrator choose the appropriate containment control and record any missing Data Access logs.
“No suspicious activity found in the logs we have” is a scoped result. State which logs and period were reviewed. Missing logs cannot establish that a credential was unused.
What should you tell clients
Use this template after filling in the facts:
Railway disclosed a credential exposure incident on 21 October. We identified [services] that stored credentials there and have [revoked or rotated] [credential categories]. Replacement credentials reached [deployments] at [UTC times]. We reviewed [provider records and time range] and found [specific result]. Work remains on [items or logging gaps]. Our next update is [time]. This message does not establish that client data was accessed; our investigation status is [status].
Avoid sending secret values or complete connection strings with the update.
When is the response complete
For every in-scope credential, keep an owner, issuer action, revocation evidence, consumer deployment evidence, and activity-review result. Use the downloadable worksheet to track those fields.
An external app scan can complement this work by examining what your deployed app exposes publicly. It cannot settle Railway account scope or prove that stolen credentials were never used. Review VAS coverage. The free preview shows the score, issue counts, and one detailed finding; subscriptions unlocking all findings start at US$19/month. See pricing.
Questions app owners ask
Does encrypted storage mean I can keep the same key
Follow the incident-specific rotation advice. Encryption at rest describes a storage control; it does not establish that a credential stayed confidential during this incident. Keep the issuer's revocation evidence with the service's replacement deployment record.
Do I need to rotate values used only by a worker
Include workers in the inventory of potentially exposed credentials. A worker is a separate consumer even if it shares a project or key with the website. Verify its replacement deployment rather than infer it from the website's health.
Cite this guide
Vibe App Scanner. “Railway security incident credential rotation checklist.” Technical sources reviewed 22 October 2026. Vendor incident scope and VAS's response workflow are identified separately; the worksheet contains no customer exposure measurements.