The Internet is not a single network. It's tens of thousands of independently owned and
operated networks; including corporates, universities, cloud providers, and telcos, to name a few. All of these networks are stitched together into something that behaves like one system. Each of these networks is called an autonomous system (AS).
Every AS is assigned a unique identifier (an AS Number, or ASN) and owns a set of IP address ranges called IP prefixes: think of these as the Internet’s equivalent of our physical world’s postal codes. When your laptop sends a request to a server on the other side of the world, that traffic doesn't travel through one pipe. It hops across a chain of these ASes, handed off at each border until it arrives.
BGP is the protocol that makes the decision on how data is handed off from one AS to the
other until it reaches its destination.
At the edges of each AS there are routers that maintain a routing table with a constantly updated list of IP address prefixes and the best available paths to reach them. These IP address prefixes are compiled from information received from neighboring ASes.
In practice it looks like this: when a data packet arrives at the AS router, the router looks up
the destination in this table and forwards it toward the next AS in the chain. And so on and
so forth until the data packet reaches its destination.
Similar to how sailors navigated the ocean hundreds of years ago with just a compass
providing a direction, BGP routes data across the Internet today. A compass cannot
let you know of bad weather, cannot tell you the shortest route, or if there are dangers lying
ahead. The same applies for BGP, the data owner has no control over the routes their data
travels through. If a path is congested, compromised, or controlled by an adversary, BGP
doesn’t know it.
Like a compass, it offers no verification: it cannot tell you if the route the data is passing
through is legitimate, or that the AS claiming to own a destination is, in fact, the owner.
This is BGP’s foundational weakness. BGP was designed in an era when the Internet was a
small community of trusted research institutions. Authentication wasn't built in because it
wasn't considered necessary. Today, any AS can announce any prefix – including one it
doesn't own – and neighboring ASes have no built-in way to verify the claim. The routing
table that underpins global Internet traffic is, in effect, largely built on trust.
Today, ships use GPS navigation systems that provide the full route, real-time conditions,
hazards ahead, and alternatives when something goes wrong. However, Internet routing
today is behind as BGP provides direction but not precision.
This is what makes attacks like BGP hijacking possible. When a malicious AS announces
prefixes it doesn't own, it can reroute traffic, with consequences ranging from traffic
interception, manipulation and network downtime.
BGP hijacking is what happens when the trust built into BGP is intentionally exploited. It
happens rather simply: a malicious actor who controls a legitimate AS broadcasts a false
announcement to neighboring ASes, claiming ownership of an IP prefix they don't own.
Because BGP has no built-in mechanism to verify these claims, neighboring routers accept the announcement, update their routing tables, and begin sending traffic toward that attacker’s AS instead of the legitimate destination. The misdirection then propagates
outward, AS by AS, until a significant portion of the Internet is sending traffic the wrong
way.
The mechanics of the attack follow directly from how BGP works, and that is why it is so
effective: every AS trusts its neighbors to announce only the prefixes they legitimately own, and that those announcements ripple across the Internet as each AS passes them along. A hijacker exploits this by injecting a false prefix announcement at one point in the network: they can corrupt routing tables far beyond their immediate vicinity.
Once traffic is flowing toward the attacker's AS, they have several options. They can drop it
entirely, causing an outage. They can inspect it such as reading credentials, intercepting
communications, or harvesting data before forwarding it to the intended destination,
leaving the victim unaware anything went wrong. This is an adversary-in-the-middle attack,
and because the traffic eventually arrives, it can go undetected - for hours, for days or even
until it's far too late.
What makes this particularly difficult to defend against is that nothing in this sequence is
technically devious. The attacker is using BGP exactly as it was designed to be used. The
announcement looks like any other. The routers are behaving correctly. In short, the
vulnerability isn't some bug you can squash, it's the protocol working as intended, but in a
world it was never designed for.
Several mechanisms have been introduced to overcome this vulnerability in the protocol,
such as RPKI. While RPKI helps reduce risk by validating the origin AS of route
announcements, it does not protect against path manipulation, adoption is incomplete, and it operates reactively.
BGP hijacking comes in different shapes, but they all take advantage of the same weakness of BGP: routers accept what they are told. There are several forms of BGP hijacking:
Prefix hijacking: Also called route hijacking or IP hijacking, this type of hijack is when an attacker announces a prefix that belongs to another AS. Any router will then send traffic to that prefix instead of the legitimate AS. This can result in traffic being intercepted or modified.
Sub-prefix hijacking: BGP routing follows a simple rule: routers send traffic to the most specific IP prefix available. In this type of hijack, the attacker announces a very specific IP prefix compared to a more general one of the legitimate owners. Then, BGP will automatically prefer the specific IP prefix over the legitimate one. The legitimate owner doesn't disappear from routing tables; they're simply outcompeted.
AS path manipulation: This a tool deployed to launch BGP hijacks in environments where RPKI is deployed. An attacker inserts false AS numbers (that appear legitimate) into the path. This gives attackers a way to influence how data enters or leaves networks – making a hijacked route look more legitimate, or to bypass basic filtering that checks whether an announcing AS is a plausible owner of a given prefix.
BGP hijacking is not theoretical. The successful exploitation of the gaps in the BGP routing
mechanism can include operational disruption, financial repercussions, regulatory exposure, and reputational damage.
The following incidents help showcase the range of BGP hijacking; from accidental
misconfigurations to deliberate attacks targeting critical infrastructure.
April 2020 - Rostelecom’s route hijack
Rostelecom announced more-specific routes for over 8,800 prefixes belonging to major
cloud and content delivery providers, including Akamai, Amazon, Alibaba, Google, and
Cloudflare. The false announcements diverted traffic through Rostelecom's network, where much of it was subsequently blackholed, causing widespread Internet connectivity
disruptions.
February 2008 - Pakistan Telecommunication Authority’s sub-prefix hijacking
In February 2008, the Pakistani government ordered its state telecom to block domestic
access to YouTube. To implement this, the Pakistan Telecommunication Authority
announced more specific routes for YouTube's IP prefixes with the intention of blackholing
domestic traffic. The routes were passed to upstream international providers and
propagated globally, taking YouTube offline for several hours. This was not a malicious
action, but one misconfiguration where Pakistan Telecommunication Authority started
advertising itself as the most specific route to YouTube, leading people to a blocked YT.
April 2010 – China’s BGP hijacking
On April 8, 2010, China Telecom managed to reroute 15% of all Internet traffic to China for
18 minutes, affecting US government and military websites, among others. While the
rerouting of data, so-called hijacking, is not always a malicious attack, researchers have
since documented a longer pattern of this behaviour.
For a chronological timeline of BGP hijacking incidents, read our blog “BGP hijacking: real-world examples and how to prevent it.”
Detection of BGP hijacking relies on a series of monitoring tools that observe routing
announcements across the Internet and flag anomalies. While these tools have improved
significantly over the past decade, they are still fundamentally reactive: they identify hijacks
after they have begun, not before.
BGPStream collects live and historical BGP data, enabling automated detection of suspicious prefix announcements and AS path changes.
These tools give visibility into what is happening on the Internet. But they can only do that
for what is visible from their vantage points, and only once the announcement has
propagated. By the time a hijack is detected, confirmed, and acted upon, traffic may have
been intercepted or disrupted for a long time.
Over the past two decades, several mechanisms have been developed to address the BGP’s lack of authentication.
RPKI, Resource Public Key Infrastructure, is the most widely deployed of these improvements. RPKI introduces a system of cryptographically signed certificates called Route Origin Authorizations (ROAs). These bind an IP prefix to the AS authorized to originate it, giving neighboring routers a basis on which to reject announcements that don't match. As of March 2026, more than >60% of IPv4 routes have ROAs. RPKI only validates the origin of a route (not the full path), causes outages due to misconfigurations, relies on manual maintenance, and introduces centralization risks.
BGPsec was designed to address exactly this gap, extending cryptographic authentication to the full AS path rather than just the origin. Standardized in 2017, it has seen almost no real-world deployment. The reasons are practical: BGPsec requires simultaneous adoption across the entire path to provide meaningful protection, creating a coordination problem that has proved difficult to overcome.
Taken together, these mechanisms improve on BGP's original design, but they do not
resolve its foundational problem. They attempt to patch a protocol that was not built with
adversarial conditions in mind.
Every corrective approach examined so far operates within the same constraint: it attempts to secure a protocol whose fundamental architecture was not designed with security in mind. SCION takes a different position entirely. Rather than extending BGP, it replaces the trust model that makes hijacking possible in the first place.
SCION (Scalability, Control, and Isolation On Next-generation networks) is a clean-slate
Internet architecture built on three principles that directly address BGP's structural
weaknesses.
Isolation domains (ISDs) are logical groups of ASes, each with its own trust anchors and routing policies. Routing anomalies, misconfigurations, and malicious announcements are contained within the domain where they originate. They cannot spread globally the way a BGP hijack does today, where a single false announcement can corrupt routing tables across the entire Internet within minutes.
Senders have full path control. Where BGP leaves senders with no visibility or influence over how their traffic is routed once it leaves their network, SCION exposes multiple verified paths to the sender and allows them to select based on latency, jurisdiction, performance, or trust. Traffic can be explicitly routed to avoid ASes in specific jurisdictions (geofencing), or to prefer paths with specific properties.
SCION does not detect hijacking. It makes hijacking structurally impossible: without
cryptographic authorization, a false route announcement cannot happen on the SCION
Internet.
For a detailed technical walkthrough, see our SCION technology webpage.
BGP hijacking is not a vulnerability that can be patched, monitored away, or solved with
better incident response. As this document has shown, the weakness is architecturally built into a protocol that has underpinned global Internet routing for more than thirty years.
Anapaya - the SCION company builds solutions based on SCION technology that give
organizations cryptographically verified, sender-controlled routing: bringing back trust at
the network layer.
For enterprises seeking to secure their connectivity without replacing their existing
infrastructure, Anapaya EDGE provides a straightforward way to the SCION network. For
service providers and network operators looking to offer SCION connectivity, Anapaya CORE enables deployment at scale.
BGP hijacking is not going to be solved with patch solutions like RPKI and BGPSEC. SCION
technology, however, provides a more secure solution against BGP hijacking for critical infrastructure that needs to be global, digital, and interconnected.