What is a BGP Hijack?
A BGP hijack occurs when a network announces IP prefixes it does not legitimately control. Because BGP is built on trust — routers generally accept route announcements from their peers without cryptographic verification — a malicious or misconfigured network can redirect traffic intended for someone else. Hijacks can result in traffic interception, denial of service, or large-scale surveillance, and have caused some of the most dramatic internet outages on record.
How BGP Hijacking Works
Every prefix in the global routing table has a legitimate originating autonomous system. Suppose Google (AS15169) legitimately announces 8.8.8.0/24. Any router on the internet that receives this announcement learns "to reach 8.8.8.0/24, send traffic toward AS15169."
A hijacker in a different AS could announce the same prefix or a more specific sub-prefix. Routers follow the longest prefix match rule, so a more-specific announcement always wins regardless of which AS announced it first.
Types of BGP Hijacks
- Origin hijack (same-prefix) — The attacker announces the exact same prefix as the legitimate holder, but with their own ASN as the origin. Routers receiving both see conflicting announcements with the same prefix length. BGP will prefer one path based on AS path length, MED, and local preference, so the hijacker's route wins only in some parts of the internet, not everywhere.
- More-specific hijack — The attacker announces a longer prefix (/25 vs /24, or /48 vs /44). Because of longest-prefix-match, this wins universally: every router prefers the more specific prefix. This is the most effective attack vector and is how the Pakistan Telecom and MyEtherWallet incidents worked.
- AS path manipulation (path hijack) — The attacker inserts their own ASN into the AS path, making it appear traffic should transit through them. Used for traffic interception (man-in-the-middle) while forwarding traffic to the legitimate destination, making the attack invisible to end users.
- Route leak — Not malicious but disruptive: a network accidentally re-announces routes learned from one peer to other peers, violating the expected traffic flow. Leaks can cause traffic to route through unintended networks. See how BGP route leaks work.
Real-World BGP Hijacks
BGP hijacks have caused major real-world disruptions:
- Pakistan Telecom vs. YouTube (2008) — Pakistan Telecom was ordered to block YouTube domestically. They announced a more-specific prefix (/24 inside YouTube's /22), which should have stayed within Pakistan. Instead, due to a misconfiguration at their upstream provider PCCW (AS3491), the announcement propagated globally. YouTube was unreachable worldwide for about two hours before the route was withdrawn.
- China Telecom (2010) — China Telecom originated routes for approximately 50,000 prefixes including US military and government networks. Traffic was rerouted through China for about 18 minutes. The incident was likely a misconfiguration, but demonstrated the potential for large-scale traffic interception.
- MyEtherWallet (2018) — Attackers hijacked routes for Amazon's Route 53 (AS16509) DNS service using a more-specific prefix. Users who tried to visit MyEtherWallet had their DNS queries answered by the attacker's server, which returned a phishing IP. Roughly $150,000 in Ethereum was stolen before the hijack was detected.
- Rostelecom (2020) — Russia's state telco announced prefixes belonging to major CDNs and cloud providers including Akamai, Cloudflare, and Amazon. The leak lasted about an hour and affected hundreds of thousands of IP addresses.
Why BGP Was Designed This Way
BGP was designed in 1989 (RFC 1105) for a small, trusted academic network where all participants knew each other. The trust model — accepting routes from peers without verification — made sense for a network of dozens of universities. With over 100,000 autonomous systems on the modern internet, that trust model is a serious vulnerability.
RFC 4271 (BGP-4, 2006) standardized the current protocol but did not add cryptographic authentication of route origin. There was no practical mechanism to verify that an AS announcing a prefix actually owned it.
Defenses Against BGP Hijacking
RPKI (Resource Public Key Infrastructure)
RPKI is the primary deployed defense. It allows IP address holders to create cryptographically signed Route Origin Authorizations (ROAs) that specify which ASNs are authorized to announce which prefixes, and the maximum prefix length allowed. Routers that perform Route Origin Validation (ROV) can drop announcements that are RPKI-invalid — those whose origin AS or prefix length does not match a ROA.
RPKI adoption has grown significantly since 2019. As of 2025, over 50% of the global routing table is covered by ROAs, and major transit providers including AT&T, Telia, NTT, and Deutsche Telekom perform ROV, meaning they discard invalid routes. However, universal deployment is still years away.
IRR Filtering
Internet Routing Registries (IRRs) like the RIPE NCC database allow networks to publish routing policies. Operators can filter BGP announcements against these records — accepting only routes that match registered prefixes and AS paths. IRR filtering is less robust than RPKI (data quality varies and records can be spoofed), but is widely deployed as a first line of defense.
BGPsec
RFC 8205 defines BGPsec, which extends BGP to carry cryptographic signatures over the full AS path, not just the origin. This prevents AS path manipulation attacks. However, BGPsec is computationally expensive and requires all ASes in a path to support it — adoption has been minimal.
Monitoring and Detection
BGP looking glasses and monitoring services like BGPmon and RIPE's RIS allow operators to detect unexpected changes in their prefix origins or AS paths. Detecting a hijack within minutes allows for rapid escalation to upstream providers to withdraw the malicious routes.
Verify Your Prefixes
You can check any prefix's current origin AS and routing path right now to verify it matches the legitimate holder: