Buried in the guides Railway published after its October 21 security incident is a sentence every developer who pulls private images from GitHub should read twice: “Those registry tokens still work on GitHub until you revoke them.” Railway removed those tokens from its own systems, but deleting a copy does not kill the original. This guide explains which GitHub credentials Railway already reset, which ones are still your job, and how to revoke GitHub tokens and look for signs that someone used them.
Where it stands: Railway’s newest status entry, posted at 01:22 UTC on Thursday, October 22 (Wednesday 9:22 p.m. in New York), said its guides “may require redeployment of services which you will not be able to complete until Builds are available again.” No update reporting that builds were back had appeared at our last check, at 01:49 UTC. Revoking a token on GitHub does not depend on Railway and can be done now.
Two GitHub links, two different outcomes
A Railway project can be tied to GitHub in two separate ways, and Railway handled them differently.
The first is the account connection that lets Railway see repositories and deploy on push. Railway invalidated those tokens itself. Its guide says “the tokens Railway held for your GitHub account connection were invalidated.” Because “Railway can’t create new GitHub tokens for you,” deploys from GitHub will not resume until you reconnect.
The second is a registry credential: a GitHub personal access token saved on a service so it can pull a private container image from GitHub Container Registry, ghcr.io. Railway says “the GitHub access tokens stored as registry credentials on your services were removed from Railway.” Removal is not revocation. In Railway’s words: “Those tokens were removed from Railway, and you must also revoke them on GitHub, because the token itself may have been exposed.”
That distinction matters because Railway’s notice of October 21 told all users to roll “any private registry credentials” along with their other environment variables. A token that Railway no longer stores can still sit, valid, in someone else’s copy.
How to revoke GitHub tokens used as registry credentials
Railway’s guide lays out the replacement in a few steps. In plain terms:
- On GitHub, go to your personal access tokens, delete the old registry token, and generate a fresh one that has only the read:packages permission.
- In Railway, open the service, go to Settings, then Source, and find Registry Credentials.
- Paste the new token into the GitHub access token field and save. Railway fills in the GHCR username itself.
- Redeploy so the next image pull uses it. While Railway builds are paused, this last step has to wait.
Repeat that for each service. Railway notes that “Registry credentials are per service,” so one project can hold several such tokens. It also notes that “Private registry credentials require the Pro plan,” which narrows who is likely to have them.
If you are unsure which token a service used, delete every classic or fine-grained token you cannot positively match to a current use. Railway’s GitHub guide goes further: “Delete tokens you don’t recognize and regenerate all tokens.”
Reconnecting Railway to GitHub
For the account connection, sign in to Railway, open Account Settings and link GitHub again. Then confirm that the Railway GitHub App still has access to the repositories you deploy, check that each service still points at the right repository and branch, and turn autodeploy back on if it was switched off during the reset.
One catch for teams: Railway says “Autodeploy works only when at least one project member has a connected GitHub account with contributor access to the repository.” If the person who originally connected GitHub has left, someone else will need to do it.
Checking GitHub for anything an intruder left behind
Revoking a token stops future use. It does not tell you whether the token was used, or whether anything was planted while it worked. Railway’s GitHub guide applies if “a GitHub token, SSH key, or password stored in Railway variables may have been exposed, or Railway deployed a commit you don’t recognize.”
| Where to look | What to look for |
|---|---|
| Account security log | Sign-ins and token or key events you did not make |
| Authorized OAuth and GitHub Apps | Apps you never approved |
| SSH and GPG keys | Keys you did not add |
| Personal access tokens | Any token you cannot account for |
| Organization audit log | Member actions on org resources |
| Each repository’s settings | New deploy keys, secrets, webhooks, collaborators |
Mind the clock on those logs. Railway notes that “GitHub logs security-relevant actions on your account for 90 days, and every integration or key,” while “Organization owners have a separate audit log that covers every member’s actions on organization resources for 180 days.” Before deleting anything, Railway advises: “Export the filtered log as JSON or CSV before you revoke anything, so the evidence survives credential deletion.”
The repository check is easy to overlook. Railway warns: “An attacker with push access can add a webhook or secret that outlives a password reset.” On the Railway side, its reset guide suggests reviewing the workspace audit log “for variable reads, registry credential changes, and deployments in the exposure window that weren’t made by your team or by Railway Staff.”
The full sequence for every other kind of secret is in our Railway rotation checklist, and the background to the incident is in our explainer on what Railway disclosed.
Why secrets around GitHub draw attackers: a separate case
GitHub is attractive to attackers for a simple reason: code, build pipelines and credentials tend to live close together there. A separate October campaign, unrelated to Railway as far as any source shows, illustrates it.
Socket’s researchers described a campaign called GhostAction, in which compromised maintainer accounts committed a malicious workflow file into repositories. Socket wrote that the newer variant “adds a regex sweep for cloud provider and AI service credentials committed into the repository and its complete git history.” Its advice to affected projects includes: “Scan the full history, not just HEAD.” More detail is in our GhostAction explainer.
The practical lesson carries over. If a key ever passed through a repository, even in a commit later deleted, treat it as exposed. Our guide on checking whether application secrets leaked covers how to search for them.
In an update to its report, Socket said it had identified “more than 500 GitHub accounts that committed the malicious workflow to tens of thousands of repositories since October 7, 2026.”
Frequently Asked Questions
Do I need to revoke GitHub tokens after the Railway breach?
If a Railway service pulled private images from GitHub Container Registry, yes. Railway removed those registry tokens from its platform, but says they still work on GitHub until you revoke them there. Any other GitHub token, SSH key or password you kept in Railway variables should also be replaced.
Why did my Railway GitHub deploys stop working?
Railway invalidated the GitHub tokens it held for account connections as part of its incident response, and it says it cannot create new GitHub tokens for you. You need to reconnect GitHub in your Railway account settings and check each service’s repository connection.
How do I check my GitHub account for unauthorized access?
Review your GitHub security log, authorized OAuth apps and GitHub Apps, SSH and GPG keys, and personal access tokens. Organization owners should also review the organization audit log and each repository’s deploy keys, secrets, webhooks and collaborators. Railway advises exporting the filtered log before revoking anything.
Is GhostAction connected to the Railway breach?
No source links them. GhostAction is a separate campaign, described by Socket, that used compromised GitHub maintainer accounts to plant a malicious workflow. It is mentioned here only as an example of why credentials around GitHub are targeted.
Sources
- Security Disclosure Recommendation: Redeploy Buckets and Reconnect GitHub After the Credential Reset — Railway (Mykal Machon), October 22, 2026
- Security Disclosure Recommendation: Check for Anomalous GitHub Access — Railway (Mykal Machon), October 22, 2026
- Security Disclosure: Wednesday October 21st — Railway (Jacob Cooper), October 21, 2026
- Railway Platform Outage — Railway status page, October 21-22, 2026 (live page, checked October 22, 01:49 UTC)
- New GhostAction Wave Hits Hundreds of Repos, Expanding Beyond CI/CD Secrets to Cloud Credentials — Socket Research Team, October 9, 2026
This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.