Railway Environment-Variable Breach. Rotate. Hunt. Contain.
An attacker accessed encrypted customer environment variables on Railway and decrypted some of them, exposing API keys, database credentials and private registry credentials. Clear steps for businesses, internal IT teams and MSPs to find exposed services, rotate every secret and hunt for misuse.
At a Glance
Facts from Railway's disclosure, status page and guidance. Last updated 22 October 2026, 13:30 BST.
Secrets exposed
Railway says an attacker accessed encrypted customer environment variables and decrypted some. Exposed values include API keys, database credentials and private registry credentials.
No CVE, no patch
This is a platform breach, not a software flaw. Root cause, IOCs and the start of exposure are not published. Only some customers are affected and Railway has not given a number.
Anything hosted on Railway
Every service you or your clients run on Railway. Railway is emailing confirmed affected customers, but rotate anyway: any secret that lived in a Railway variable should be treated as exposed.
AI inference keys targeted
Railway believes this is part of a wider campaign against platform companies aimed at AI inference provider keys. Expect misuse of cloud and AI credentials, not only Railway access.
A researcher reports crypto wallets with keys stored on Railway drained, the first theft at least two hours before disclosure.
Railway publishes its security disclosure: encrypted environment variables accessed and some decrypted.
Railway rotates storage bucket credentials, invalidates Railway API tokens, resets GitHub tokens and asks upstream providers to revoke keys.
Builds back for Pro and Enterprise. Hobby, Free and Trial being restored. Railway emails confirmed affected customers.
Rotate every variable, reconnect GitHub, redeploy bucket users, then hunt cloud, AI and database logs for misuse.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Tick both tracks.
Find and rotate
- List every client and internal service hosted on Railway.
- Rotate every environment variable: API keys, database passwords, cloud keys and registry credentials.
- Create new Railway API tokens. All old ones were invalidated.
- Reconnect GitHub and redeploy anything that uses storage buckets.
Hunt for misuse
- Check logs of every service whose keys lived on Railway.
- AWS and GCP: new IAM users or keys, unfamiliar projects or billing links.
- AI usage spikes in Bedrock, Vertex AI and AI provider dashboards. Database logins from unknown IPs.
- Check transfers to the reported wallet. If you find misuse: revoke, preserve logs, run incident response.
Proactive: Find Exposure and Rotate
Work through every Railway workspace you are responsible for. Railway recommends rotating every variable, not only the ones that look sensitive.
Find every service on Railway
Build a list of every project, environment and service on Railway across your business and every client you manage, including old and test projects. For each one record which variables hold secrets and which system issued them. The free checker below lists variable names (never values) and writes a rotation checklist.
Rotate every variable
Rotate at the issuing system first, then update Railway: cloud keys (AWS, GCP), AI provider keys, database passwords and connection strings, private registry credentials, payment and webhook secrets. Revoke the old value, do not just add a new one. Prioritise anything with cloud, billing or production data access.
Re-issue Railway tokens and reconnect
Railway invalidated all Railway API tokens, so create new ones for CI, scripts and tooling. Reconnect GitHub, because Railway reset GitHub tokens, and redeploy any service that uses Railway storage buckets so it picks up the rotated bucket credentials.
Move to a vault and short-lived credentials
Keep secrets in a vault and use short-lived credentials (OIDC or workload identity) instead of long-lived keys where you can. Use least privilege and set spend caps on AI providers. Never store wallet private keys or seed phrases in environment variables.
Free Checker Scripts
Built by the CybaVerse threat hunt team. Run them against your own Railway workspaces and cloud accounts, or every client you manage, to get a rotation checklist and a clear verdict.
Check-RailwayExposure (PowerShell and Bash)
Lists every Railway project, environment and service the token can see, and the names of variables that look like secrets, with a rotation hint for each. Values are read into memory only to get the names and are never printed or written. Writes a CSV rotation checklist.
export RAILWAY_TOKEN=<new token>
./check-railway-exposure.sh
pwsh ./Check-RailwayExposure.ps1 -OutFile checklist.csvNeeds a newly created Railway account or workspace token, because Railway invalidated all existing tokens.
check-aws-new-iam.sh
Lists IAM users and access keys created since the hunt start (default 14 October). Covers IAM users and keys only, not roles, policies or other resources.
SINCE=2026-10-14T00:00:00Z ./check-aws-new-iam.shNeeds the AWS CLI with read access to IAM.
Read-only by design
The scripts only read. The Railway checker sends GraphQL queries and refuses mutations, and the AWS checker only lists IAM users and keys. They change nothing and write only local report files. Rotation and revocation stay with you. Review any script before you run it.
Verdicts
- 0Nothing found that needs action.
- 1Action needed: secret-like variables or new IAM users or keys found. Rotate and investigate.
- 2Unknown or partial: for example CLI mode covers only the linked project.
- 3Error, including no credentials. The result is unknown.
Exit codes
| Code | Meaning |
|---|---|
| 0 | Nothing found |
| 1 | Action needed |
| 2 | Unknown or partial |
| 3 | Error |
MSPs and internal IT teams can use the exit code in RMM or deployment tooling to flag hosts at scale.
Know the limits
- Behaviour-based only. Railway has published no IOCs, so nothing here matches known attacker infrastructure.
- The wallet address comes from one researcher and is unverified by Railway.
- The 14 October lookback start is a CybaVerse assumption, not a Railway date. Widen it if your logs allow.
- The KQL has not been run on a live tenant and the checkers were tested against mocks only. Validate table and column names first.
- The Railway checker needs a newly created token, since all old tokens were invalidated. Name matching is heuristic, so rotate everything anyway.
Reactive: How to Hunt
Treat any use of a secret that lived on Railway from an unexpected source as an incident. Rotation stops new misuse, but IAM users, keys or projects an attacker created stay in place until you remove them. CybaOps can run these hunts across your estate or your clients'.
Services whose keys lived on Railway
For every service whose credentials were stored in a Railway variable, review its own access and audit logs from 14 October (our lookback assumption) for use from unfamiliar IPs, new locations or unusual volumes.
AWS and GCP persistence
In AWS CloudTrail, check every Region for CreateUser, CreateAccessKey, AttachUserPolicy, CreateRole, PutBucketPolicy and RunInstances. In GCP audit logs, look for new service accounts or keys, IAM binding changes, unfamiliar projects and new billing links.
SINCE=2026-10-14T00:00:00Z ./check-aws-new-iam.shAI usage spikes
Compare Bedrock and Vertex AI usage, and each AI provider dashboard, against your normal baseline. Spike hunts need Bedrock CloudTrail data events and GCP Data Access logs for Vertex AI enabled. Revoke any AI key showing unexpected use.
Database logins
Review database authentication logs for logins from unknown IPs since 14 October. If your Railway services use static outbound IPs, allowlist them so anything else stands out.
Wallets and response
If wallet keys or seed phrases were ever stored in a Railway variable, check for transfers to the researcher-reported address below on a public block explorer, and move remaining funds to a new wallet generated offline. If you find misuse anywhere: revoke the credential, preserve logs and run incident response.
Detection pack: KQL and Sigma
Behaviour-based hunts from the CybaVerse threat hunt team for Microsoft Sentinel and Defender XDR (AWS CloudTrail, GCP audit logs and database sign-ins): IAM persistence, activity in new Regions, Bedrock and Vertex AI spikes, service account keys, IAM changes and unknown database logins. Eight Sigma rules cover the same behaviour for any SIEM. Run them in CybaOps or your own tooling.
No IOCs are embedded because none were published. The KQL has not been run on a live tenant, so validate table and column names and set your known-good IPs before relying on results.
KQL hunting queries (Sentinel and Defender XDR)
Loading queries. If they don't appear, download the full pack below. The .kql file is inside it.Sigma: AWS IAM persistence after key exposure
title: AWS IAM Persistence Activity Possibly Using Exposed Access Key
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b01
status: experimental
description: IAM user/key/role/policy creation listed in Railway's 2026-10-22 guidance as signs of misuse of exposed AWS keys. Baseline against your own automation.
references:
- https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.persistence
- attack.t1098.001
- attack.t1136.003
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: iam.amazonaws.com
eventName:
- CreateUser
- CreateAccessKey
- AttachUserPolicy
- PutUserPolicy
- CreateLoginProfile
- CreateRole
- AttachRolePolicy
- PutRolePolicy
- UpdateAssumeRolePolicy
condition: selection
falsepositives:
- Legitimate IaC pipelines and administrators
level: mediumSigma: AWS GetCallerIdentity key testing
title: AWS STS GetCallerIdentity Credential Validation
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b04
status: experimental
description: GetCallerIdentity is commonly the first call made with stolen keys. Correlate with source IPs not in your baseline or egress ranges.
references:
- https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.discovery
- attack.t1087.004
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: sts.amazonaws.com
eventName: GetCallerIdentity
condition: selection
falsepositives:
- SDKs, CLIs and CI frequently call this
level: informationalSigma: AWS bucket policy change or RunInstances
title: AWS PutBucketPolicy or RunInstances Possibly Using Exposed Access Key
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b02
status: experimental
description: Calls named in Railway's AWS guidance (RunInstances, PutBucketPolicy). Scope to keys that were stored in Railway.
references:
- https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-aws-access
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.impact
- attack.t1496
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventName:
- RunInstances
- PutBucketPolicy
condition: selection
falsepositives:
- Normal deployments
level: lowSigma: AWS Bedrock model invocation
title: AWS Bedrock Model Invocation
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b03
status: experimental
description: Bedrock invocation events. Railway links the campaign to targeting AI inference provider keys; alert on principals/regions with no prior Bedrock use (threshold/baseline in SIEM).
references:
- https://blog.railway.com/p/security-disclosure-wednesday-october-21st
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.impact
- attack.t1496
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventSource: bedrock.amazonaws.com
eventName:
- InvokeModel
- InvokeModelWithResponseStream
- Converse
- ConverseStream
condition: selection
falsepositives:
- Legitimate AI workloads (requires baselining)
level: lowSigma: GCP service account key creation
title: GCP Service Account or Key Creation
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b05
status: experimental
description: New service accounts or keys, named in Railway's GCP guidance as signs of misuse of exposed service account keys.
references:
- https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-gcp-access
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.persistence
- attack.t1098.001
logsource:
product: gcp
service: gcp.audit
detection:
selection:
gcp.audit.method_name|contains:
- CreateServiceAccountKey
- CreateServiceAccount
- UploadServiceAccountKey
condition: selection
falsepositives:
- Legitimate administration
level: mediumSigma: GCP IAM policy change
title: GCP IAM Policy Change
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b06
status: experimental
description: New IAM bindings (incl. Service Account Token Creator), named in Railway's GCP guidance.
references:
- https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-gcp-access
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.privilege-escalation
- attack.t1098
logsource:
product: gcp
service: gcp.audit
detection:
selection:
gcp.audit.method_name|endswith: SetIamPolicy
condition: selection
falsepositives:
- Legitimate administration
level: mediumSigma: GCP project, billing, SSH key or compute change
title: GCP New Project, Billing Link, Project SSH Key or Compute Instance
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b07
status: experimental
description: Resource creation consistent with abuse of exposed credentials (Railway guidance lists compute instances, buckets and project-level SSH keys).
references:
- https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-gcp-access
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.impact
- attack.t1496
logsource:
product: gcp
service: gcp.audit
detection:
selection:
gcp.audit.method_name|contains:
- CreateProject
- UpdateProjectBillingInfo
- setCommonInstanceMetadata
- compute.instances.insert
- storage.buckets.create
condition: selection
falsepositives:
- Normal deployments
level: lowSigma: GCP Vertex AI usage
title: GCP Vertex AI Prediction Calls
id: 2f0b7c3e-6a41-4c1e-9b8a-1d2e3f4a5b08
status: experimental
description: Vertex AI prediction/generation calls (Data Access logs required). Railway's GCP guidance names Vertex AI as a common abuse target; baseline in SIEM.
references:
- https://blog.railway.com/p/security-disclosure-recommendation-check-for-anomalous-gcp-access
author: Defensive detection pack
date: 2026-10-22
tags:
- attack.impact
- attack.t1496
logsource:
product: gcp
service: gcp.audit
detection:
selection:
gcp.audit.service_name: aiplatform.googleapis.com
gcp.audit.method_name|contains:
- Predict
- GenerateContent
condition: selection
falsepositives:
- Legitimate AI workloads
level: lowWhat indicators exist
There are no official IOCs, so hunting is behaviour-based. The wallet address comes from one independent researcher and has not been confirmed by Railway. A match needs investigation in context, and a clean search does not rule out exposure.
# Railway has published NO indicators of compromise: no IPs, domains, hashes or user agents.
# Root cause and the start of the exposure window are also not published.
# Researcher-reported only (Taylor Monahan). UNVERIFIED. Not mentioned by Railway.
# Wallet that received funds drained from crypto wallets whose keys were stored on Railway:
0xd9773325282874d18cb83f1fe50f14c39750b2ee
# Hunt window used in the CybaVerse pack (our assumption, not a Railway date):
2026-10-14T00:00:00Z to nowRailway Breach FAQ
Short answers based on Railway's disclosure and status page as of 22 October 2026.
What happened at Railway?
Railway says an attacker accessed encrypted customer environment variables and decrypted some of them, exposing API keys, database credentials and private registry credentials. There is no CVE. Root cause has not been published.
Am I affected?
Only some customers were affected and Railway has not said how many. Railway is emailing confirmed affected customers, but any secret stored in a Railway variable should be rotated whether or not you get an email.
Has the stolen data been used?
Independent researcher Taylor Monahan reports that crypto wallets whose keys were stored on Railway were drained, with the first theft at least two hours before disclosure. This is unverified by Railway.
What has Railway done?
Railway rotated storage bucket credentials, invalidated Railway API tokens, reset GitHub tokens and asked upstream providers to revoke keys. Builds are back for Pro and Enterprise, and Hobby, Free and Trial are being restored.
Are there IOCs to search for?
No. Railway has not published IPs, domains, hashes or an exposure start date, so hunting is behaviour-based: new IAM users and keys, unfamiliar projects, AI usage spikes and unknown database logins.
What should MSPs do first?
List every client service on Railway, rotate every variable at the issuing system, create new Railway tokens, reconnect GitHub, then hunt AWS, GCP, AI and database logs for each client.
Detect and Remediate Railway Exposure Across Your Estate
CybaOps monitors cloud, identity and application activity across every environment you look after, whether that's your own business or your clients'. Our SOC runs these threat hunts, alerts on new IAM users and keys, AI usage spikes and unknown logins, and drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.