BGP is the protocol that holds the internet together. Every network announces “I can reach this prefix” and every other network believes it. That trust model worked when the internet was a small academic network. Today it makes BGP one of the most fragile pieces of internet infrastructure.
This post is the practical history: how BGP hijacks happen, the most consequential incidents, the technical countermeasures (especially RPKI) that have grown up around the protocol, and what’s actually changed in 2026.
The Anatomy of a BGP Hijack
A BGP hijack happens when an AS announces a route it shouldn’t. The announcement propagates; other networks accept it; traffic that should have gone elsewhere now flows to (or through) the announcing AS.
The two main flavors:
Prefix hijack
AS-A announces “I’m the origin for 8.8.8.0/24” when in reality Google’s AS15169 is. If AS-A is well-connected (Tier-1 transit, etc.), the false announcement spreads, and traffic to 8.8.8.x flows to AS-A instead of Google. AS-A can drop it (DoS), inspect it (snoop), or rewrite responses (MITM).
More-specific hijack
Google announces 8.8.8.0/24. AS-A announces 8.8.8.0/25 — a more specific (smaller, contained) prefix. BGP’s longest-prefix-match rule means routers prefer the more-specific route. Traffic to 8.8.8.0-127 flows to AS-A.
This second form is harder to detect because the legitimate announcement is still present; only a portion of the address space is hijacked.
Famous Incidents
Pakistan vs YouTube (2008)
Pakistan Telecom tried to block YouTube domestically by announcing a more-specific route into their own network. The announcement leaked to international peers; suddenly all YouTube traffic worldwide flowed to Pakistan, where it was dropped. YouTube was effectively offline globally for ~2 hours until the route was withdrawn.
This was the first widely-reported case showing how a domestic configuration mistake could break a global service. Lesson: BGP announcements don’t stay inside one country unless explicitly filtered.
China Telecom (2010)
A Chinese state-affiliated AS announced routes for ~50,000 prefixes, briefly absorbing significant fractions of global internet traffic. The traffic was routed through China before being passed on. Whether it was intentional surveillance or a configuration error has been debated.
This incident contributed heavily to subsequent geopolitical pressure for RPKI deployment.
Indosat (2014)
Indonesian ISP Indosat accidentally announced ~400,000 prefixes — most of the internet — for a few hours. Cause: a routing-protocol configuration error during a BGP migration. Effect: significant routing instability worldwide.
Lesson: even non-malicious mistakes can have outsized impact. BGP doesn’t care about intent.
Amazon Route 53 hijack (2018)
Attackers hijacked AWS DNS service routes to redirect traffic for myetherwallet.com (an Ethereum wallet) through their own infrastructure. They presented a fake SSL certificate, but users who clicked through warnings lost cryptocurrency. ~$150,000 USD was stolen.
Lesson: BGP hijacks can be used for targeted financial fraud, not just espionage or DoS.
Telstra’s accidental Cloudflare/Apple/Google leak (2020)
Australian ISP Telstra leaked routes during a maintenance window, briefly absorbing significant Apple, Cloudflare, and Google traffic into Australia. Service degradation lasted ~10 minutes.
Lesson: every major internet operator is one operator error away from being a global outage source.
KQED / Verizon and the Cloudflare incident (2019)
Pennsylvania-based small ISP DQE Communications leaked routes via Verizon. The leak absorbed traffic for Cloudflare, Amazon, and other major networks. Cloudflare’s incident report blamed BGP’s lack of validation.
This was a watershed moment — Cloudflare’s blog post advocating for RPKI adoption catalyzed a wave of major networks finally signing their routes.
Why BGP Is So Fragile
A few reasons BGP has been vulnerable for decades:
No built-in authentication
BGP itself doesn’t verify “is this AS authorized to announce this prefix?” Routes are accepted based on the AS’s peering relationships and the configured policy. If a peer says “I have a route for X,” neighbors believe them.
Peering trust
Tier-1 networks peer with each other based on commercial agreements. The peering relationship implicitly trusts what the other side announces. A misconfigured peer can propagate bad routes upstream.
Route propagation is global
A route accepted by one peer propagates to that peer’s peers, and so on. A single bad announcement can spread to thousands of networks within minutes.
Filtering is hard
“Filter out routes you shouldn’t be receiving” sounds easy. In practice, networks have thousands of customers, each announcing many prefixes; keeping the filters accurate requires constant maintenance.
The RPKI Response
RPKI (Resource Public Key Infrastructure) is the modern answer to BGP’s authentication gap. It works like this:
- Resource owners sign certificates binding their allocated prefixes to the AS(es) authorized to announce them. These are called ROAs (Route Origin Authorizations).
- The certificates are published by RIRs (ARIN, RIPE, APNIC, etc.) in publicly accessible repositories.
- Networks deploying RPKI validation check incoming BGP announcements against the published ROAs.
- Routes with invalid origins are dropped or deprioritized.
Practical effect: a malicious or misconfigured network can’t successfully announce someone else’s prefix if the rightful owner has published a ROA and the receiving networks validate.
RPKI Adoption State in 2026
Adoption has accelerated dramatically:
- ~50% of all global prefixes have valid ROAs in 2026 (up from ~10% in 2020).
- Major Tier-1 networks (Lumen, NTT, Telia, GTT, Cogent, AT&T) all do RPKI validation on customer announcements.
- Cloudflare, AWS, Google, Microsoft have all signed their prefixes and validate incoming announcements.
- The “BGP route security” goal — getting >95% of major prefixes ROA-protected — is plausibly achievable in the next 3-5 years.
You can check the state of your own prefixes at rpki-monitor.antd.nist.gov or bgp.tools. Significant networks that don’t have valid ROAs in 2026 are increasingly the exception.
Detecting Hijacks
Even with RPKI, hijacks still happen — sometimes deliberate, sometimes from networks that don’t validate. Detection mechanisms:
Route monitoring services
ThousandEyes, BGPmon, Cisco’s Crosswork Network Insights — services that continuously monitor BGP announcements and alert on unexpected changes. Your prefix suddenly being announced by an AS you don’t recognize triggers an alert.
Looking glasses
Public BGP looking glasses (bgp.tools, bgp.he.net, RIPE’s RIS) let you see the current routing for any prefix. Comparing what you see to what you expect catches obvious anomalies.
Internal monitoring
Your AS’s own BGP table is the source of truth for your routing. Compare announced routes against your intended policy continuously.
What This Means for Application Developers
Most application developers will never operate BGP. But hijacks affect you indirectly:
Outages from BGP problems
When a major site is unreachable, BGP issues are a common (if less-publicized) cause. Knowing what BGP is helps you reason about “the internet is broken right now” incidents.
Geolocation drift
Sustained BGP changes (legitimate prefix transfers, for instance) eventually appear in geolocation databases. Short-term hijacks don’t, but they can cause brief weirdness in your geolocation data while the hijack is active.
Trust models
Any system that depends on “the IP I’m seeing is from where I think it is” can be broken by BGP manipulation. For high-stakes fraud detection, be aware that nation-state adversaries can manipulate routing.
Why HTTPS matters
A BGP hijack alone doesn’t necessarily mean compromise — if your traffic is HTTPS, the attacker still needs to break TLS to read or modify it. This is one of the reasons “encrypt everything” is the modern default.
What’s Coming Next
The frontier in 2026:
BGPsec
A protocol-level extension that signs BGP messages, not just origins. Slow to deploy because it requires every router on the path to validate signatures. Still in the early stages.
Path validation
Where RPKI validates “this AS is authorized for this prefix,” path validation tries to verify “this AS path is valid.” Harder problem; still researched, not yet widely deployed.
Automated response
Modern routing platforms (BIRD, FRRouting, vendor systems) increasingly include automatic responses to anomalous routes — drop, deprioritize, alert. This is becoming production-ready.
IETF and operational coordination
The IETF SIDROps working group continues to develop the routing-security protocol stack. MANRS (Mutually Agreed Norms for Routing Security) provides a checklist for network operators to demonstrate basic hygiene.
Practical Action Items
If you operate a network:
- Sign your prefixes with ROAs. This is the single most impactful thing you can do.
- Deploy RPKI validation. Drop invalid origins from your route imports.
- Monitor your prefixes for unexpected announcements. Free tools cover most needs.
- Join MANRS. A public commitment to routing-security basics.
- Filter your customers. Every announcement they make should be one you’ve authorized.
If you don’t operate a network:
- Use HTTPS everywhere. TLS protects against payload-level consequences of BGP hijacks.
- Use DNSSEC where possible. Adds another layer of integrity.
- Be aware that “the internet is down” sometimes means BGP, not your application.
TL;DR
- BGP hijacks happen because BGP trusts its peers without authentication.
- Major incidents (Pakistan/YouTube, Indosat, MyEtherWallet, Telstra) have shaped routing security.
- RPKI is the modern fix — sign your prefixes; validate incoming announcements.
- 2026 adoption is ~50% of global prefixes and accelerating.
- Even RPKI doesn’t prevent all hijacks — you also need monitoring and operational hygiene.
- HTTPS protects payload even when routing is manipulated.
BGP security has improved dramatically in the last five years. It’s far from perfect, but the protocol is no longer the wide-open trust model it was a decade ago. For more on BGP basics, see BGP routing explained; for the ASN level, what is an ASN. For application-level monitoring of where IPs actually come from in 2026, the Ip2Geo API is the layer above all of this.