What is BGP hijacking? How route hijacks work and how to stop them

02What types of BGP hijack are there?

03How does a hijack unfold?

At a conceptual level, the major incidents follow the same sequence.

• Announcement: a router starts originating a prefix, by mistake, through a careless or compromised customer, or deliberately
• Acceptance: neighbours accept the route because nothing in their filters rejects it, and pass it on
• Propagation: within minutes, networks that prefer the new route redirect traffic for those addresses
• Exploitation or outage: traffic is dropped, answered by impostor servers or relayed onwards
• Withdrawal: the hijacker removes the route, an upstream filters it, or the holder out-competes it

04Route leaks vs hijacks: what is the difference?

RFC 7908 defines a route leak as "the propagation of routing announcement(s) beyond their intended scope". The origin is usually correct; the problem is the path. A customer that passes routes learned from one provider to another, or a network that re-announces its peers' routes to its transit, becomes an unintended detour for traffic it cannot carry.

The best-documented example happened on 24 June 2019. A BGP optimiser at DQE Communications generated more-specific versions of routes it had learned and announced them to its customer Allegheny Technologies, which passed them to its other transit provider, Verizon, and Verizon propagated them. Cloudflare reported losing about 15% of its global traffic at the worst point. Because the leaked routes were more specific than the originals, they won wherever they reached.

For the victim, intent makes no difference: a mistaken leak and a deliberate hijack look the same in a traffic graph, and the defences overlap.

05Famous BGP hijacks and leaks, with dates

Six incidents with primary write-ups show how the technique has moved from accidental blackholes to targeted certificate theft.

06How to detect a hijack of your prefixes

You will not notice a partial hijack from inside your own network, because your routers still see your own announcement. Detection needs an outside view from many vantage points, which route collectors such as the RIPE NCC's Routing Information Service (RIS) provide in real time. BGPalerter, an open-source tool from NTT, reads the public RIS Live feed and alerts on the patterns below for the prefixes you configure.

For a one-off check from a script, RIPEstat's API answers who is announcing a prefix now; when something looks wrong, a traceroute from outside shows where the traffic actually goes.

• A new origin ASN for one of your prefixes
• A new more-specific prefix inside your space, from any origin
• Your prefix appearing with an unexpected neighbour next to your ASN, the fingerprint of a forged origin
• Your announcements becoming RPKI-invalid, or not found after you published ROAs
• A sudden drop in traffic from particular networks or regions while your own routers look normal

# origin ASN(s) currently seen for a prefix
curl -s 'https://stat.ripe.net/data/prefix-overview/data.json?resource=193.0.0.0/21'

# visibility across RIS peers, origins and more-specifics
curl -s 'https://stat.ripe.net/data/routing-status/data.json?resource=193.0.0.0/21'

# RPKI status of that origin and prefix
curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS3333&prefix=193.0.0.0/21'

07How to defend against BGP hijacking

No single control is enough. The list builds on the MANRS actions for network operators, such as filtering, coordination and global validation, and adds newer measures. Path validation is the missing piece: ASPA, which lets an AS publish its authorised upstream providers so that forged paths can be detected, was still an IETF draft in October 2026.

• Publish ROAs for every prefix you announce, with maxLength equal to the announced length; see what RPKI is
• Publish AS0 ROAs for space you hold but do not route
• Drop RPKI-invalid routes on your own routers
• Filter customer announcements against IRR and RPKI data, generated with a tool such as bgpq4, and set max-prefix limits on every session
• Keep your own IRR route objects accurate, so others can filter correctly
• Enable BGP roles (RFC 9234) where supported, so leaks are detected at the session
• Monitor your prefixes from outside, and keep a runbook with your upstreams' contacts
• Watch certificate transparency logs for certificates issued for your domains that you did not request

08BGP hijacking and DDoS protection

Routing-based DDoS protection uses the same mechanism as a hijack, with permission. The protection provider announces your prefix, or a more specific part of it, so that traffic including the attack reaches its network first. The difference is authorisation: a ROA naming the provider's ASN, published in advance, makes that announcement valid while an attacker's stays invalid.

The overlap matters in two more ways. A hijack of a protected prefix pulls traffic away from the scrubbing network altogether, so monitoring your prefixes is part of protecting them. And from outside, a hijack outage looks like an attack outage, with traffic vanishing for some users, so checking who announces your space is an early step in incident triage, alongside the steps in how to stop a DDoS attack.