Cloudflare BYOIP BGP Withdrawal: When an Automated Script Erases Your Addresses

Your IP Addresses Just Stopped Existing

There is a specific flavor of network failure that is genuinely difficult to diagnose quickly: the one where your service produces no response at all rather than an error response. No HTTP 503, no TCP RST, no ICMP unreachable. Just silence. Client connections time out with no indication of where in the path the problem is.

This is what Cloudflare’s enterprise customers using Bring Your Own IP (BYOIP) experienced on February 20, 2026. Their IP address ranges vanished from the global internet routing table. From the perspective of every router between a client and those services, the destinations simply ceased to exist. Packets bound for those addresses had nowhere to go, so they were dropped silently.

The cause was a bug in an automated internal maintenance script that caused Cloudflare to unintentionally withdraw customer IP address advertisements from BGP. The script was designed for legitimate maintenance operations on Cloudflare’s network. The bug caused it to withdraw routes it should not have touched.

BGP and Why Route Withdrawal Is So Damaging

Border Gateway Protocol is the routing protocol that determines how traffic flows across the internet at a macro level. When a network wants to announce that it can reach a range of IP addresses, it advertises those routes to its BGP peers. When a route is withdrawn, the announcement is rescinded, and the internet’s routers update their tables to reflect that the network advertising those addresses is no longer reachable via that path.

For most enterprises, their IP address blocks are advertised by their hosting provider or CDN continuously. Cloudflare’s BYOIP service allows enterprises to bring their own IP address ranges and have Cloudflare advertise those ranges from its global network, providing the performance and protection benefits of Cloudflare’s edge without forcing customers to change their IP addresses.

When the maintenance script withdrew those customer route advertisements, Cloudflare’s edge network stopped telling the internet where to send traffic for those IP ranges. Globally, within the BGP convergence window of a few minutes, traffic bound for affected customer addresses had no route. The addresses did not return errors because there was nothing at the network layer to generate errors. They simply did not exist.

The Diagnosis Problem

The silent failure mode creates a specific operational challenge. When a service returns an error, the engineering team responsible for that service typically receives alerts through monitoring systems that check HTTP responses, gRPC health endpoints, or similar application-level signals. A 503 response triggers an alert. A timeout often does not trigger the same alert in the same way, particularly if monitoring infrastructure is itself routing through the affected addresses.

Teams whose services vanished from BGP on February 20 would have seen, from their own monitoring, complete connection failure. But the absence of response is harder to attribute than a specific error code. Without knowledge of the BYOIP routing issue, a team might reasonably investigate their own application, their database, their service mesh, or their cloud provider’s compute infrastructure before considering that their IP addresses had been withdrawn from internet routing tables.

Cloudflare identified the root cause in the automation script and halted the maintenance task. The fix was straightforward: restart the BGP advertisements. Route propagation across the internet takes a few minutes as peering routers update their tables. The outage lasted approximately one hour and forty minutes from initial failure to full route restoration.

Automation at Network Scale

The incident highlights a risk that grows as infrastructure automation becomes more sophisticated and more deeply trusted. Maintenance scripts that interact with network routing infrastructure operate at a layer where mistakes have immediate, global impact. A misconfigured application deployment might break a service. A misconfigured BGP manipulation script can remove an organization’s entire internet presence.

The usual software development practices, code review, testing in staging environments, gradual rollout, are harder to apply to BGP operations because staging environments cannot fully replicate the behavior of the global internet routing table. A script that works correctly in a test environment against a subset of routes can have unexpected behavior when run against production routing infrastructure at full scale.

Radia Perlman, who spent decades working on network protocols and coined the term “Mother of the Internet” for her work on spanning tree protocol, has written about the fundamental fragility of routing systems that depend on correct behavior from all participants. BGP was designed for trust between cooperating networks. Scripts with bugs are not cooperating partners.

The appropriate control for automation that touches BGP is conservative access controls, human approval gates for any operation that modifies route advertisements, and explicit scope limitations that prevent maintenance scripts from operating outside their intended boundaries. Cloudflare’s post-incident actions presumably moved in this direction, though the specifics of their remediation were not fully detailed publicly.

Two Cloudflare Outages in 24 Days

February 20 was Cloudflare’s second significant outage in less than a month. January 27 had seen a different failure, a node cascade beginning in Chicago, affect customers across North America and Europe. Two separate, unrelated incidents within 24 days at a provider whose core value proposition is network reliability raises questions that enterprise customers are right to ask.

The incidents were technically unrelated. One was a node propagation failure in the edge network. One was an automation bug affecting BGP route management. Different systems, different root causes, different mitigation paths. But the accumulation of incidents in a short window is operationally significant regardless of whether the individual root causes are connected.

Enterprise customers who had evaluated BYOIP as a way to combine their own IP infrastructure with Cloudflare’s network capabilities had a reasonable expectation that their IP addresses would remain continuously advertised. February 20 demonstrated that this expectation had a vulnerability in the automation layer that manages those advertisements.

References

1. Cloudflare status page, BYOIP BGP withdrawal incident, February 20, 2026
2. Cloudflare blog, post-incident report, BYOIP service disruption
3. The Register, “Cloudflare automation script withdraws customer BGP routes globally,” February 2026
4. DataCenterDynamics, “Cloudflare second major incident in February 2026,” February 2026
5. Radia Perlman, “Interconnections: Bridges, Routers, Switches, and Internetworking Protocols,” Addison-Wesley Professional