On January 22, 2026, Cloudflare experienced a short but impactful routing mistake: an automated configuration change in Miami unintentionally leaked BGP routes. The result was that some Internet traffic that should never have touched Cloudflare's Miami network was briefly pulled through it, affecting both Cloudflare customers and external networks.
The good news is that the incident was limited in scope and time. The bad news is that even a short route leak can create real congestion and confusing side effects across the Internet.
What happened in plain English
A route leak happens when a network accidentally tells the Internet, "Send that traffic to me," even though it is not the right place to deliver it. In this incident, a router in Cloudflare's Miami data center began advertising IPv6 routes it should have kept internal. That caused some traffic to detour into Miami, where parts of it were slowed down and some of it was dropped.
Cloudflare noted that:
Quick refresher: what a BGP route leak is
BGP is the system networks use to tell each other how to reach destinations on the Internet. Every route advertisement includes a path of networks (ASNs) it has traversed, called the AS path.
A route leak occurs when routes learned from one relationship type (like a peer) get incorrectly passed on to another relationship type (like a transit provider). That breaks standard "valley-free" routing expectations and can redirect huge volumes of traffic to a network that is not prepared or intended to carry it.
Cloudflare stated this incident matched route leak categories described in RFC7908, involving more than one leak type.
Timeline of the incident (UTC)
| Time (UTC) | Event |
| 19:52 | A code change that later triggered the policy bug was merged into network automation |
| 20:25 | Automation ran on a single Miami edge router and began unexpected advertisements to peers and transit providers (impact start) |
| 20:40 | Network team began investigating unintended route advertisements |
| 20:44 | Incident coordination initiated |
| 20:50 | A network operator manually reverted the bad configuration and paused automation on the router (impact stop) |
| 21:47 | The triggering change was reverted from the code repository |
| 22:07 | Automation validated as safe to run again on the Miami router |
| 22:40 | Automation unpaused on the Miami router |
Root cause: a policy change that became too permissive
The change that set everything off was intended to be routine: Cloudflare removed certain BGP announcements in Miami that were previously used to forward some IPv6 traffic toward their Bogotá data center. After infrastructure upgrades, that routing workaround was no longer needed.
The problem was not the goal, but the effect of the configuration diff.
By removing specific prefix list terms, the resulting routing policy became overly broad. It treated "internal" route types as acceptable in a way that unintentionally allowed internal IPv6 prefixes to pass through an export policy and get advertised externally to Miami's BGP neighbors.
In other words, the filter that should have been picky became too welcoming, and internal-only routes escaped into the wider Internet.
What the impact looked like on the network
Once those advertisements went out, Miami started receiving traffic it wasn't supposed to carry. That created two main effects:
Traffic detouring through Miami caused congestion on backbone paths connected to the region (including links toward Atlanta), increasing latency and packet loss for some traffic.
Some of the leaked traffic was not meant for Cloudflare services or customers. Router firewall filters, designed to protect the network by rejecting irrelevant traffic, discarded a portion of it. Cloudflare reported that at peak, a significant amount of inbound traffic in Miami was dropped because it did not match allowed destinations.
Fix and recovery
Mitigation was swift once the cause was identified:
Follow-ups: how Cloudflare plans to prevent a repeat
Cloudflare described several improvements aimed at preventing similar incidents, covering both immediate fixes and longer-term routing safety.
Improvements inside Cloudflare's automation and routing policies
Improvements that help route leak prevention more broadly
Closing note
Cloudflare apologized for the disruption and emphasized that route leaks are easy to trigger accidentally, especially when automation and routing policy logic intersect. This incident is a reminder that even well-run networks can slip up, and that the best defense is layered: safer policy design, better automation guardrails, and Internet-wide routing security improvements that catch mistakes before they spread.
If you want, I can also turn this into a shorter "news post" version (around 500 to 700 words) for your blog front page, while keeping the same headings.
Comments