Route leak in Miami: What happened on January 22

On January 22, 2026, a routing policy misconfiguration pushed through Cloudflare's automation platform caused a BGP route leak from a router in our Miami data center. The leak lasted 25 minutes and affected both Cloudflare customers and external networks, whose traffic was inadvertently funneled through Miami. Congestion on backbone links between Miami and Atlanta caused elevated packet loss and latency, and some leaked traffic was dropped by firewall filters configured to accept only traffic destined for Cloudflare services and customers. At peak, roughly 12Gbps of ingress traffic was discarded.

The incident affected IPv6 prefixes only. We apologize to the users, customers, and networks impacted.

How the leak happened

At 20:25 UTC, our policy automation platform applied a change to remove BGP announcements from Miami for one of our data centers in Bogotá, Colombia. The removal was intentional: recent infrastructure upgrades meant IPv6 traffic no longer needed to be forwarded through Miami toward Bogotá. The generated configuration diff appeared benign, only removing prefix lists containing BOG04 unicast prefixes. However, the resulting policy was too permissive.

The policy began marking every prefix of type "internal" as acceptable and adding informational communities to all matching prefixes. Critically, it also accepted routes through the policy filter, which meant an intended "internal" prefix would be advertised externally. The "route-type internal" match in JunOS and JunOS EVO—the operating systems on our HPE Juniper Networks devices—matches any non-external route type, including Internal BGP (IBGP) routes. All IPv6 prefixes redistributed internally across our backbone were thus accepted and advertised to every BGP neighbor in Miami.

When the misconfigured policy was applied, a series of unintended BGP updates were sent from AS13335 to peers and providers in Miami. For example, the first update for prefix 2a03:2880:f077::/48 shows the AS path 64112 22850 174 3356 13335 32934: we took the prefix received from Meta (AS32934), our peer, and advertised it toward Lumen (AS3356), an upstream transit provider. Routes received from peers should only be readvertised downstream to customers—not laterally to peers or up to providers. Per RFC7908, the leak was a mixture of Type 3 and Type 4 route leaks.

The incident is similar in nature to a previous outage documented in 2020.

Mitigation and next steps

We are taking a multi-pronged approach to prevent future route leaks, both in our own configuration and through broader industry efforts.

Internal fixes

  • Patching the routing policy automation failure that caused the leak and mitigating similar potential failures
  • Adding BGP community-based safeguards that explicitly reject routes received from providers and peers on external export policies
  • Integrating automatic routing policy evaluation into CI/CD pipelines to catch empty or erroneous policy terms
  • Improving early detection of network configuration issues and negative effects from automated changes

Industry-wide prevention

  • Validating routing equipment vendors' implementation of RFC9234 (BGP roles and the Only-to-Customer Attribute), which is the only policy-independent way to prevent route leaks at the local autonomous system
  • Encouraging long-term adoption of RPKI Autonomous System Provider Authorization (ASPA), which would let networks automatically reject routes with anomalous AS paths

We are actively involved in IETF and infrastructure community efforts to strengthen routing security. Route leaks are easy to cause accidentally, as this incident shows, and preventing them requires coordinated work on multiple fronts. We again apologize for the impact on Cloudflare users, customers, and external networks.