Railway says forged scanning traffic, not a breach, is why some networks have blocked its IP addresses since November 4, 2026. A third party is sending scanning traffic that carries Railway's source addresses. Security vendors and network operators then blacklist those addresses. Users on affected networks cannot reach Railway-hosted apps or railway.com. At the latest update, November 5 at 18:51 UTC, some users had regained access, but the incident was still open as a partial outage.
This post sticks to what Railway's status page says, adds context from Railway's earlier October 21 security disclosure, and separates fact from open questions. It also covers what teams should do when a platform they depend on is caught in a reputation problem it did not cause.
TL;DR: what is confirmed and what is not
| Question | Answer | Source |
|---|---|---|
| Are users losing access? | Yes. Some users cannot reach Railway-hosted apps or railway.com | Railway status page |
| Why? | Network providers and security services blocked Railway IP addresses | Railway status page |
| Who sent the traffic? | A third party, using forged Railway source IPs | Railway's account |
| Was Railway breached? | Railway says the spoofing needs no access to its infrastructure and is not evidence of compromise | Railway's account |
| Tied to October 21? | Railway found no evidence of a tie | Railway's account |
| Is it fixed? | No. Partial outage, with some users restored as of November 5, 18:51 UTC | Railway status page |
| Who is behind it? | Not known publicly | None |
| Why Railway? | Not stated | None |
Agents that act on your behalf need rules. See how explainx helps secure your agents →
What the status page says, in order
Railway's incident has three public entries so far. Each builds on the one before.
November 4, 18:54 UTC. Railway said some users could not reach Railway-hosted applications or railway.com because network providers and security services had blocked Railway IP addresses. It confirmed that a third party was sending scanning traffic using forged Railway source IP addresses. It said that traffic "does not originate from Railway's network". It added that the spoofing does not require access to Railway infrastructure and that the reports are not evidence of a compromise. It also said it had found no evidence of any tie to the October 21 security incident. Railway promised to work with providers and vendors to correct reputation listings.
November 4, 22:03 UTC. Access stayed affected on networks that block Railway addresses. Railway said it had submitted review requests to security vendors and had no estimated time for all networks to remove their blocks. It invited network administrators to use the incident notice to review affected rules and permit legitimate access while keeping protections against unsolicited scanning traffic.
November 5, 18:51 UTC. Some users reported restored access. Railway said it had contacted network operators, security vendors and abuse database providers, and that access remained affected from some networks. It repeated that switching networks may help in the meantime.
The same page also lists a separate scheduled maintenance on a core database for Saturday, November 7, from 23:00 to 23:30 UTC. Railway says running services and databases are not affected by that window. It is unrelated to the blocks.
The uptime bars on the page show a dent for the month. At the time we read it, public networking and the railway.com dashboard each showed 98.94% for November. That figure is Railway's own measurement of its status components, and it does not describe how many users were cut off on their own networks.
How forged source addresses cause this kind of outage
Cable unplugged beside dim status lights, showing a Railway outage where blocked IP addresses cut off reachability
Most readers will not need the packet details, but the mechanism explains why Railway cannot simply fix this itself.
Every IP packet carries a source address. For protocols such as TCP, a full connection needs replies to reach the sender, so a spoofer cannot hold a normal conversation with a forged address. But a scanner does not need a conversation. It can fire probe packets at many targets, and the targets log the apparent source. A firewall, intrusion-prevention system or abuse-reporting tool then sees "Railway's address scanned me". Many such tools feed shared reputation lists. Once an address is listed, every customer of that vendor blocks it by default.
This is the same family of reputation attacks that has long been used against mail servers and DNS resolvers. The target is not the network that gets scanned. It is the owner of the address that gets blamed.
Three details make it hard to clean up:
- The owner cannot stop the packets. They do not leave its network, so firewall rules on Railway's side change nothing.
- Blocks are scattered. Each vendor, each ISP and each enterprise firewall holds its own copy of the listing. Railway must file reviews with each, as it says it is doing.
- A cloud host shares addresses. Many apps sit behind the same edge addresses. When those addresses are listed, every customer behind them loses reach on affected networks, including customers who did nothing.
The status page says "scanning traffic" and does not give volumes, ports or the networks that are blocking. We do not know how large the campaign is or whether it is still running. We also cannot confirm from public sources which vendors have listed Railway addresses.
Why this matters for people who deploy on Railway
If you host an app on Railway, the practical effect is uneven. Your app may be fine from your laptop and unreachable from a customer's office or a mobile carrier. That is a hard failure mode to diagnose, because your own health checks may pass.
Reasonable steps today:
- Test from more than one network. Try a mobile hotspot, a home connection and a cloud probe. If one fails and another works, a network-level block is likely.
- Tell affected customers what to ask for. Share Railway's incident notice with their IT team, as Railway suggests, so the team can allow legitimate access.
- Do not rotate secrets because of this alone. Railway says the event is not evidence of compromise. Secrets rotation was the right response to the October 21 disclosure, but nothing in this incident asks for it.
- Plan a fallback for critical endpoints. A second region, a second provider for a status page, or a CDN in front of the app reduces exposure to one provider's reputation problem.
- Watch the status page, not social posts. The status page is the primary source and is updated by Railway.
The context: a hard month for Railway
Siren light and wrench illustrating incident response after the Railway security disclosures
Railway has now had two separate public incidents in about two weeks, plus a third story that involved one of its engineers.
- October 21. Railway disclosed anomalous activity involving systems that store customer environment variables. It said an unauthorized third party may have accessed encrypted environment variables and, for some, obtained decrypted contents. It recommended that all users roll every environment variable and paused deployments. Railway said it believed this was part of a series of attacks on platform companies aimed at compromising AI inference providers. Our write-up covers what stolen AI API keys mean for users.
- November 3. A Primcloud founder accused a Railway engineer of an attack, and the engineer admitted his testing agents went too far. The details came mostly from one side, as we laid out in the claimed-versus-verified post on Railway and Primcloud.
- November 4 and 5. The forged-source blocking described above.
Railway says the third item is not tied to the first. It has made no public statement connecting the blocks to the Primcloud story. We cannot rule out a link, because the status page does not say who is sending the traffic, and we have no evidence of one. Readers should treat any claim of a link as unverified until Railway or an independent party shows it.
One thing is worth noticing, though. When a company becomes visible in a dispute about scanning, it is plausible that third parties might use its addresses as a convenient label for scans. That is speculation, and the status page does not say it. We flag it only so readers understand why the timing draws attention.
How this compares with other infrastructure incidents we have covered
Cloud and AI infrastructure incidents tend to fall into three shapes. This one is the third.
| Shape | Example | What users lose |
|---|---|---|
| Provider failure | Google Cloud London power event that took down Revolut | Service from the provider itself |
| Credential theft | GitBook incident and attacker API tokens, LLMjacking | Secrets and money, often silently |
| Reputation attack | Railway, November 4 and 5 | Reachability from some networks, with no breach |
The third shape is the least discussed, and it is the one where the victim has the fewest tools. In a provider failure, the fix is to restore the service. In credential theft, the fix is to rotate keys. In a reputation attack, the fix depends on dozens of outside parties agreeing to remove a listing. We keep a running list of this month's attacks in our November 2026 cyberattacks tracker.
What to do if you run agents or automation that scan things
The Railway story is a reminder of why scanning hygiene matters, even when this specific incident is not caused by an agent. Security vendors and abuse desks cannot tell your authorized scan from an attack by looking at one packet.
- Scan only systems you own or have written permission to test.
- Give automated agents an explicit network allowlist and log every outbound connection.
- Route all testing through known, documented source addresses so a defender can match your scans to your contact details.
- Keep the abuse contact for your address ranges current, so a reporter can reach you before blocking you.
For teams that let AI agents run commands, AgentBeam is the agent security platform from the explainx.ai team. It stops AI agents before they take dangerous actions, such as scanning hosts you did not authorize.
What we do not know
Several questions are open, and we will not guess at them.
- Who is sending the traffic and why. Railway has not said.
- How many networks block Railway addresses. Railway says some, and gives no count.
- How long the cleanup takes. Railway says it has no estimate.
- Whether the campaign continues. The status page describes the activity in the present tense on November 4. It does not say it stopped.
- Whether customers were harmed beyond lost reach. Railway says there is no evidence of compromise, and no outside review exists.
If Railway publishes a post-incident report, it should answer some of these. We will add an update section here if it does.
Bottom line
On the evidence available on November 5, 2026, this is a reachability problem, not a data breach. Railway says forged scanning traffic got its addresses listed, that its own network is not the source, and that it found no link to the October 21 incident. The fix lies partly with outside vendors and network operators. If your app is on Railway, test from several networks, point affected users to the incident notice, and avoid rotating secrets on this signal alone.
Related reading
- Railway engineer's AI agents and Primcloud: claimed vs verified
- Railway and OpenRouter attacks: stolen AI API keys and what to do
- GitBook security incident: rotate your secrets
- LLMjacking and stolen cloud AI access
- Google Cloud London power event: what is confirmed
- November 2026 cyberattacks tracker
Details are accurate as of November 5, 2026, 18:51 UTC, the latest status entry we read. Check status.railway.com for current information.