News · Issue 17
Why the same BGP prefix leak recurred six years after the first postmortem
Six years of postmortems and RPKI deployment later, BGP route leaks still propagate the same way because the protocol enforces nothing and the structural fixes are half-deployed.
Recurring failure
Same leak, different year
On January 22, 2026, Cloudflare published a postmortem for a route leak incident. The failure mode was familiar: a network announced routes it learned from one provider to another, propagating them beyond their intended scope. The same class of failure has been documented in postmortems going back to at least 2019. Standards were written, mitigation tools shipped, and it keeps happening.
- Jun 2019 (SafeHost / China Telecom)
- Apr 2020 (RIPE / Rostelecom)
- Aug 2023 (Bangladesh / Brazil)
- Jan 2026 (Cloudflare postmortem)
Each incident gets a postmortem. Each postmortem identifies misconfigured export filters as the root cause. And each time, the fix depends on every operator along the path doing the right thing voluntarily, because BGP itself enforces nothing about who is allowed to announce what to whom.
June 2019
40,000 routes, four hours
The canonical example is the SafeHost (AS21217) leak of June 6, 2019. SafeHost announced more than 40,000 IPv4 routes it had learned from peers and providers to its upstream provider China Telecom (AS4134), which accepted and propagated them globally. The leak lasted almost four hours and affected more than 6,000 different origin ASes, with services including WhatsApp, Microsoft, banks, and CDNs caught in the crossfire.
The AS_PATH showed SafeHost doing AS path prepending, as if trying to discourage China Telecom from using the link, but China Telecom accepted the routes anyway. There was no prior evidence of a BGP connection between the two ASes in pre-incident data. The configuration error propagated because nothing in the protocol stopped it.
The mechanism
RPKI catches the wrong problem
RPKI Route Origin Validation validates that an ASN is authorized to originate a prefix. But most route leaks are path leaks: the origin is correct, the AS_PATH is wrong, and RPKI has nothing to say about that.
The August 2023 Bangladesh leak proved this. AS58715 leaked roughly 30,000 BGP routes to transit provider BTCL, of which 12,588 were RPKI-valid. 85.4% of Kentik's BGP sources would have routed Microsoft traffic through Bangladesh.
RFC 9234 — A 2022 standard that defines BGP roles (provider, customer, peer, route server) negotiated in the OPEN message, with an Only-To-Customer (OTC) attribute set automatically on ingress and checked on egress. If roles mismatch, the BGP session fails to establish.
RFC 9234 is the structural fix. If roles are configured, the OTC attribute blocks peer-learned routes from going upstream. But both sides need to support it, and deployment is still nascent.
The consequence
34% and climbing slowly
The reason the same failure recurs is deployment. As of 2021, roughly 34% of global address space had valid ROA coverage, against a 70% target. ASPA, designed to validate AS_PATH relationships, remains in early stages.
RPKI ROV
stops origination leaks, ~34% ROA coverage
RFC 9234 + ASPA
stops path leaks, deployment nascent
Qrator Radar recorded over 12 million BGP route leaks in Q3 2022 alone, from 3,030 unique leakers. More than 70% of 2021 incidents were detected by fewer than 20 peers, meaning most propagate before anyone notices.
Ephemeral leaks: the problem underneath the problem
Many leaks detected by Cloudflare Radar are "ephemeral leaks," brief anomalies during BGP convergence lasting seconds or less. One detected leak existed for less than one second from a single vantage point.
BGP trusts every speaker to follow policy, and trust is not a security model.
Every mitigation requires operators to opt in and coordinate with neighbors. As long as a single AS on the path hasn't deployed the relevant mechanism, a leak propagates through it. Postmortems keep finding the same root cause because the protocol has no enforcement layer.
Wrap-up
Trust is not a security model
Why it matters
Route leaks are a structural flaw in BGP that no postmortem will fix on its own. The protocol trusts every participant to filter correctly, and the mitigations that would replace trust with enforcement, RPKI ROV, RFC 9234 BGP roles, and ASPA, each cover a different slice of the problem and each remains incompletely deployed. Engineers operating networks on the public internet still need to filter on both import and export sides, because they cannot assume the AS on the other end is doing the same.
The short version
- BGP route leaks have recurred in postmortems from June 2019 through January 2026, always with the same root cause: misconfigured export filters.
- RPKI ROV stops origination leaks but does not catch path leaks where the origin is correct and the AS_PATH is wrong.
- RFC 9234 BGP roles and the OTC attribute would structurally prevent most path leaks, but deployment is still nascent.
- RPKI ROA coverage sat at ~34% of address space as of 2021, against a 70% target, and the path-leak fixes are even further behind.
- The protocol has no enforcement layer; every mitigation requires voluntary operator adoption and coordination with neighbors.