What is a BGP route leak?

An announcement of routes beyond their intended scope, typically passing routes learned from one provider to another in violation of policy. Traffic is then drawn toward a network that should not carry it, causing congestion, loss, and latency, or making the affected prefixes unreachable.

Why does a more specific prefix win in BGP?

Because routers select routes by longest prefix match, which is fundamental to how forwarding works. Announcing a smaller subnet of an address range attracts traffic for that subnet regardless of path length or policy, which is why both hijacks and accidental more-specific announcements are so effective.

Does RPKI prevent route leaks?

Not on its own. Route origin validation confirms that the network originating a prefix is authorised to do so, which addresses origin hijacks. In a leak the origin is legitimate and the path is wrong, so preventing leaks requires path and relationship signalling such as BGP roles and provider authorisation records.

How do you detect a route leak affecting your network?

From outside it. Public route collectors and monitoring services show how your prefixes appear globally and can alert on unexpected announcements or changed paths. Internal monitoring cannot see how the rest of the internet is routing toward you, which is exactly what needs observing.

How BGP Route Leaks Break the Internet

A BGP route leak occurs when routes learned from one peer are announced to another in violation of the intended policy, pulling traffic through a network that should not carry it. Because BGP propagates announcements without verifying authorisation, a single misconfiguration can redirect traffic globally until filtering stops it.

The mechanism

BGP is how independent networks tell each other which address ranges they can reach. A network announces the prefixes it originates, and its neighbours propagate those announcements onward according to policy. The protocol has no inherent way to know whether an announcement is legitimate; it carries what it is told, and routers select the best available path.

Two properties make mistakes consequential. First, longest prefix match: a more specific announcement always wins over a less specific one, so announcing a smaller subnet of someone else's space attracts their traffic regardless of anything else. Second, propagation is fast and wide, so an announcement accepted by one upstream can reach much of the internet within minutes.

The distinction between a leak and a hijack is intent and shape rather than effect. A hijack means announcing address space you do not hold. A leak means announcing routes you legitimately learned, but to a party your policy says should not receive them, typically taking routes learned from one provider and passing them to another. Both pull traffic toward a network unable to carry it, producing congestion, loss, latency, and sometimes total unreachability for the affected prefixes.

Why the damage is rarely the leaker's fault alone

Most leaks are configuration errors, and configuration errors are inevitable. The reason some become global incidents and most do not is whether the upstream applied filtering. A provider that accepts whatever its customer announces is the mechanism by which a local mistake becomes everyone's outage. This is why the remedies concentrate on validation at the boundary rather than on preventing mistakes, since the mistakes will keep happening.

Three documented incidents

A network leaking its own routes, January 2026. Cloudflare published a postmortem on 23 January 2026 for a route leak the previous day. An automated routing policy change intended to remove certain announcements became overly permissive: removing prefix-list restrictions left the policy matching all internal route types, so internal BGP routes were accepted and redistributed externally. It affected IPv6 only. Per that postmortem the leak began at 20:25 UTC when the policy applied to a router, an incident was raised at 20:44, and a manual revert ended the impact at 20:50, about 25 minutes. The consequences described were backbone congestion between two sites with elevated loss and latency. Remediations listed included patching the policy automation, BGP community safeguards, automatic routing-policy evaluation in the deployment pipeline, and adoption of BGP roles and autonomous system provider authorisation.

A route optimiser generating more specifics, June 2019. Cloudflare published an analysis on 24 June 2019 describing a leak that began at 10:30 UTC. A BGP optimiser at a regional ISP split received prefixes into more specific announcements, including splitting one Cloudflare range into two halves, and those propagated to a large transit provider that applied no filtering at that peering. Cloudflare reported roughly 15 percent of its global traffic affected at peak. Widely repeated figures for total prefixes and duration come from third-party reporting rather than that postmortem.

A blackhole route escaping, February 2008. RIPE NCC published a case study on a well-known incident in which an operator, acting on a domestic order to block a video site, announced a more specific prefix intended to blackhole that traffic locally. The announcement reached its upstream and propagated globally. Per RIPE NCC's timeline the unauthorised announcement began at 18:47 UTC, the legitimate holder counter-announced at 20:07, announced two more specific halves at 20:18 which won on longest prefix match, and the upstream withdrew the offending routes at 21:01.

What actually prevents propagation

Prefix filtering at customer boundaries. The most effective single control. A provider should accept from a customer only the prefixes that customer is authorised to announce, built from a maintained list rather than trust. Every large leak involves a boundary where this was absent.

Route origin validation. Cryptographically signed statements about which network may originate a prefix let routers reject announcements from the wrong origin. It addresses origin hijacks well and does not by itself stop leaks, because in a leak the origin is correct and the path is wrong.

Path and role signalling. Declaring the relationship on a session, such as customer or peer, lets routers detect announcements inconsistent with that relationship, which is precisely the shape of a leak. Provider authorisation records extend this by stating which networks may legitimately appear as a prefix's upstream.

Maximum prefix limits. A session that suddenly carries far more prefixes than normal is a strong leak signal, and a configured limit that tears the session down is a blunt but effective circuit breaker.

Treat routing policy as code. The January 2026 postmortem is notable because the trigger was automation that became too permissive when a restriction was removed, and the remediation was evaluating policy changes in a pipeline. Routing policy has the same properties as any other configuration: it deserves review, testing against expected output, and staged rollout.

Monitor your own prefixes from outside. Public route collectors and monitoring services will tell you when someone else announces your space or when your announcements change unexpectedly. You cannot see this from inside your network, which is what makes external observation necessary.

Be careful with optimisers. Tools that improve routing by generating more specific announcements are, mechanically, generating exactly what a leak looks like. If they are used, their output must not escape, and the 2019 incident is the standing example of what happens when it does.

Frequently asked questions

What is a BGP route leak?: An announcement of routes beyond their intended scope, typically passing routes learned from one provider to another in violation of policy. Traffic is then drawn toward a network that should not carry it, causing congestion, loss, and latency, or making the affected prefixes unreachable.
What is the difference between a route leak and a hijack?: A hijack means announcing address space you do not hold. A leak means announcing routes you legitimately learned, but to a party your policy says should not receive them. The effect on traffic is similar; the difference matters because the defences are not the same.
Why does a more specific prefix win in BGP?: Because routers select routes by longest prefix match, which is fundamental to how forwarding works. Announcing a smaller subnet of an address range attracts traffic for that subnet regardless of path length or policy, which is why both hijacks and accidental more-specific announcements are so effective.
Does RPKI prevent route leaks?: Not on its own. Route origin validation confirms that the network originating a prefix is authorised to do so, which addresses origin hijacks. In a leak the origin is legitimate and the path is wrong, so preventing leaks requires path and relationship signalling such as BGP roles and provider authorisation records.
How do you detect a route leak affecting your network?: From outside it. Public route collectors and monitoring services show how your prefixes appear globally and can alert on unexpected announcements or changed paths. Internal monitoring cannot see how the rest of the internet is routing toward you, which is exactly what needs observing.