What is a BGP hijack?

A BGP hijack happens when a network operator announces, via the Border Gateway Protocol, that it can deliver traffic for an IP prefix that actually belongs to someone else. Because BGP has no built-in identity check, the announcement propagates to peers, and a portion of the global internet starts forwarding the affected traffic to the wrong network — where it can be inspected, redirected, or dropped.

Is BGP hijacking always malicious?

No — most BGP hijacks in the historical record have been operator error rather than attacks. A misconfigured customer router leaks the operator's full table back upstream; a typo in a route policy announces a /24 instead of the intended /16; a fat-fingered censorship attempt at one ISP leaks to the global table. Malicious hijacks do happen (especially around cryptocurrency exchanges and named state-level operations), but they are the minority of incidents that actually reach Twitter.

What is RPKI and does it actually work?

RPKI (Resource Public Key Infrastructure) is a system where IP-resource holders publish digitally-signed Route Origin Authorizations stating which ASNs can announce which prefixes. Routers that perform Route Origin Validation reject announcements that conflict with a published ROA. As of 2026 the major Tier-1 backbones and most large CDNs validate, so the technology demonstrably works — it does not stop path manipulation, but it prevents the simple origin-spoofing class of hijack entirely.

How would I know if my prefix had been hijacked?

RIPE Stat shows the current set of ASNs announcing any prefix in their database — if an unexpected origin appears, you have evidence of a hijack or a leak. Commercial monitoring services like BGPmon and Kentik can send real-time alerts when anything unusual happens to your address space. For the most-watched prefixes (DNS roots, anycast resolvers, large cloud providers), watchdog projects publish public dashboards.

BGP hijacking — how it works, who does it, and how the internet defends

The unverified announcement at the heart of the internet

BGP — the Border Gateway Protocol — is how the ~75,000 networks that make up the public internet tell each other "I can reach prefix X via me." A router at one ISP speaks BGP with its peers and customers; each announcement propagates outward; over a few minutes the global routing table converges and the whole internet has a shared view of where to send each chunk of address space.

The catch is that BGP has no built-in identity verification. When AS-12345 announces that it can reach 198.51.100.0/24, there's no protocol field that says "I am authorized to do this" — the recipient just trusts it and passes it on. The trust model is "we all know each other, we all behave," which worked when the internet was a few thousand networks and stopped working long ago.

When a network announces a prefix it doesn't actually own — by mistake or on purpose — the announcement spreads, and a chunk of internet traffic starts arriving at the wrong destination. That's a BGP hijack.

How a hijack actually happens

Every ASN (see the ASN glossary) speaks BGP with its neighbors at internet exchange points and over private peering links. When a router learns multiple paths to the same destination, it picks the "best" one using a chain of decision rules: most-specific prefix wins, then highest local preference, then shortest AS-path, and so on through a dozen tiebreakers.

The first rule is the lever attackers pull. There are three common hijack patterns:

More-specific hijack. If the legitimate owner announces 198.51.100.0/24 and an attacker announces 198.51.100.128/25 — a tighter, more-specific cut — every router prefers the more-specific match even though it came from a different origin. This is the most effective and most common kind of hijack because it doesn't even compete with the legitimate announcement; it cleanly takes priority.
Same-prefix hijack. The attacker announces the exact same prefix from a different origin AS. Routes split based on each receiver's policy — networks geographically close to the attacker tend to prefer the hijacked route, networks close to the legitimate owner stay on the right one. The result is a partial hijack: maybe 30% of traffic goes the wrong way.
Path manipulation. The attacker doesn't claim to own the prefix — they claim to be a shorter transit path to it. Traffic flows through the attacker's network where it can be inspected, logged, or selectively dropped. This is the sneakiest form: from the legitimate origin's perspective, the prefix is "still theirs"; the impact is on traffic that's being silently rerouted on the way back.

Incidents that shaped how the internet thinks about BGP

Pakistan vs. YouTube — February 2008

Pakistan's government ordered local ISPs to block YouTube. Pakistan Telecom (AS17557) implemented this by announcing 208.65.153.0/24 — a more-specific cut of YouTube's range — internally, as a black-hole route. The announcement was supposed to stay inside Pakistan. It didn't. Pakistan Telecom's upstream provider, PCCW (AS3491), accepted the announcement and passed it on. Within two minutes, most of the global BGP table believed Pakistan Telecom was the right place to send YouTube traffic. YouTube was effectively unreachable worldwide for about two hours. This is the textbook BGP hijack incident and the one that prompted serious investment in BGP defenses across the industry.

NSA-Google "Belgacom" route divergence — 2013

Reporting based on Snowden documents revealed that some Google-bound traffic had been routed through Belgian transit in ways that appeared to permit intelligence collection. The post-incident BGP timelines didn't quite fit a clean hijack, but the incident solidified the industry's understanding that path-level interference was an active threat, not just a theoretical one. Public-key path verification (BGPsec) was revived as a serious work item after this.

Indosat — April 2014

An Indonesian ISP, Indosat (AS4761), announced about 320,000 prefixes it didn't own for roughly three hours. The cause was almost certainly a misconfiguration that re-originated the operator's full inbound table back to its upstream. The result was a wave of partial outages affecting Akamai, Apple, and many CDN-fronted sites. No malice; just a typo that scaled to the world.

Russia Telecom — December 2017

About 80 prefixes belonging to Mastercard, Visa, Symantec, and others were briefly routed through AS12389 (Rostelecom) in Russia. The leak lasted minutes; the attribution and intent remain debated; the attention was massive because of the combination of targets and origin. Spurred several large enterprises to publicly adopt RPKI for the first time.

Cloudflare's 1.1.1.1 — July 2024

Eletronet (a Brazilian ASN) announced the more-specific 1.1.1.0/24 route via a peer that did not filter properly. About 6% of global resolver traffic for Cloudflare's public DNS landed at the wrong place for a few hours before the route was withdrawn. Cloudflare attributed it publicly and used the incident as a high-profile case for accelerating RPKI deployment across the rest of the industry.

The modern defense stack

BGP hijacking has three classes of defense, each addressing a different part of the problem. None is sufficient alone; together they raise the cost of a successful hijack considerably.

1. RPKI + ROAs (origin validation)

A Route Origin Authorization (ROA) is a digitally-signed statement published by an IP-resource holder: "ASN X is authorized to originate prefix Y, up to maximum length Z." The five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC) host the trust anchors; networks publish ROAs covering their own resources.

Routers that perform Route Origin Validation (ROV) drop or deprefer announcements that conflict with a ROA — an unauthorized origin can no longer simply inject a fake announcement into the global table. As of 2026, the major Tier-1 backbones (Lumen, Cogent, NTT, Telia/Arelion, Tata, Sparkle) and most large CDNs (Cloudflare, Fastly, Akamai, AWS) validate. Cloudflare publishes their ongoing measurement at isbgpsafeyet.com.

ROA coverage of the global address space is now over 50% of routed prefixes — high enough to make origin hijacks much harder than they were in 2017, but still leaving half the table protected only by old-school filtering.

2. IRR filtering

Internet Routing Registries (RADb, AltDB, the RIR-hosted IRRs) hold older, less cryptographically rigorous route objects — declarations of "this AS originates these prefixes" maintained by hand. Most networks still generate their customer prefix filters from IRR data because it predates RPKI and currently covers more of the table. IRR filtering is brittle (a stale or wrong object lets through what should be blocked) but it's better than nothing, and it's the belt-and-braces complement to ROV.

3. Path validation (ASPA, BGPsec)

ROV protects against origin hijacks. It does not protect against path manipulation, where an attacker correctly identifies the origin but pretends to be a short transit path to it. ASPA (Autonomous System Provider Authorization) is the new layer: ASNs publish a list of their legitimate transit providers, and routers refuse to accept paths that violate the topology those declarations describe.

BGPsec — cryptographic per-hop path signing — has been on the IETF books since 2017 but has near-zero production deployment because every router would need to perform a signature check on every received announcement, at a cost most operators don't think is worth paying yet. ASPA is the lighter-weight middle ground.

How to monitor your own prefixes

Even if you can't do much about a hijack happening, you can find out about it immediately and start the contact-your-peers process. Tools that send alerts when something unexpected happens to your routes:

RIPE Stat. Free, web-based, queryable per-prefix. Shows historical and current origin ASNs. Run a query against your own prefix today to baseline.
BGPmon (Cisco). Commercial real-time monitoring with email/Slack alerts. Free tier for small operators.
NLNOG RING. Cooperative network of probe boxes inside hundreds of ASNs around the world; member organizations can run traceroutes from any of them. Free for ASN operators willing to host a box themselves.
Kentik, ThousandEyes, Catchpoint. Commercial network-monitoring platforms with BGP visibility built in. The right tier for enterprises with multi-region presence and SLA-bound services.

What can you actually do?

If you operate an ASN: publish ROAs for every prefix you announce. The RIRs' web tools make this 10-minute work, no engineering required. Don't deploy strict ROV on customer-facing routers until you're confident your filtering won't accidentally drop legitimate traffic from peers who haven't published ROAs yet — most operators run ROV in monitor mode first.
If you're a customer of an ISP: ask whether they validate ROV inbound. "RPKI-safe" networks publish their stance publicly.
For your own watch: set up at least one continuous monitor (free BGPmon tier or your own RIPE Stat polling) on every prefix you care about. The time between "hijack happens" and "Twitter notices" is usually 5-30 minutes; the time between "hijack happens" and "your monitor pings you" can be under one.
Use IPFerret's ASN pages. /asn/<asn> surfaces the currently-announced prefixes from RIPE's view of the global BGP table — handy for sanity-checking what the internet thinks about a given network at any moment.

BGP hijacking, in plain English