Cloudflare Suffers IPv6 BGP Route Leak After Automation Error at Miami Data Center

Cloudflare has disclosed details of a Border Gateway Protocol route leak incident that occurred on January 22, 2026, after an automated routing policy misconfiguration unintentionally advertised IPv6 prefixes from its Miami data center to external networks. The incident, which lasted approximately 25 minutes, affected Cloudflare customers and several third-party networks whose traffic was mistakenly rerouted.

The company acknowledged responsibility for the event, noting that while it frequently analyzes and documents route leaks across the Internet, it rarely finds itself as the originating source. Cloudflare issued an apology to customers, users, and external networks impacted by the disruption.

What Is a BGP Route Leak

A BGP route leak occurs when a network advertises routes to upstream providers or peers that it is not authorized or intended to propagate. In technical terms, this happens when an Autonomous System appears unexpectedly in an AS path, violating established valley-free routing rules.

Under normal conditions, routes learned from a peer or provider should only be re-advertised to downstream customer networks. When this rule is broken, large volumes of traffic can be misdirected through infrastructure that is not designed to handle it.

Timeline of the January 22 Incident

The sequence of events began at 19:52 UTC, when a change was merged into Cloudflare’s network automation code repository. At 20:25 UTC, automation was executed on a single edge router in Miami, triggering unintended BGP advertisements to transit providers and peers.

Engineers identified the abnormal routing behavior within minutes. By 20:50 UTC, the misconfiguration was manually reverted and automation was paused on the affected router. Full cleanup and validation of the automation workflow were completed later that evening, with automation safely re-enabled at 22:40 UTC.

Root Cause of the Misconfiguration

The issue stemmed from a change intended to stop forwarding IPv6 traffic from Miami to a data center in Bogotá, Colombia, following infrastructure upgrades. While the change appeared minor, it removed specific prefix-list filters from multiple routing policies.

This resulted in policies that were overly permissive, allowing all routes marked as internal to be accepted and exported externally. Because JunOS treats internal route types broadly, a large number of internal IPv6 prefixes were inadvertently advertised to peers and upstream providers.

Impact on Traffic and Customers

The route leak caused congestion on Cloudflare’s backbone links between Miami and Atlanta, leading to elevated packet loss and increased latency for some customer traffic. External networks whose prefixes were leaked also experienced issues, as traffic destined for them was redirected into Cloudflare’s Miami infrastructure.

At peak, Cloudflare reported discarding roughly 12 Gbps of unintended inbound traffic due to firewall filters designed to only accept traffic destined for Cloudflare services and customers.

Detection and Visibility

The unintended advertisements were visible through public BGP monitoring tools and route collectors, where anomalous AS paths showed Cloudflare redistributing routes learned from peers toward upstream providers. This pattern clearly matched established definitions of route leaks under RFC7908.

Cloudflare noted that the incident closely resembled a previous routing outage experienced in 2020, reinforcing the complexity and risk associated with large-scale network automation.

Preventive Measures and Next Steps

In response, Cloudflare is patching the automation logic that allowed the policy failure and introducing additional safeguards. These include stricter community-based export controls, automated routing policy validation in CI/CD pipelines, and earlier detection of unintended configuration side effects.

Longer term, the company is supporting industry-wide efforts such as BGP roles with the Only-to-Customer attribute and broader adoption of RPKI Autonomous System Provider Authorization. These measures aim to reduce the likelihood and impact of accidental route leaks across the Internet.

The incident underscores how even well-instrumented networks can be affected by subtle configuration changes, particularly as automation becomes central to Internet-scale operations.