In February 2008, Pakistan tried to censor YouTube for its own citizens and briefly took it offline for the rest of the planet.
The government had ordered YouTube blocked over a video. Pakistan Telecom’s plan was mundane: announce a route for a chunk of YouTube’s address space inside its own network, so Pakistani traffic to YouTube would hit a wall instead of the site. That part worked. The problem was that the fake route didn’t stay inside Pakistan. Pakistan Telecom handed it to its upstream provider, which passed it to the rest of the internet, and for something like two hours a large slice of the world’s YouTube traffic got routed toward a network in Pakistan that was trying to throw it away.
Nobody hacked YouTube. Nobody broke TLS. A single network told a lie about which addresses it could reach, and the internet believed it — because believing each other is the only thing BGP knows how to do.
The bug that never got fixed
I wrote before about how BGP runs on trust — the Border Gateway Protocol that stitches the internet’s networks together has no built-in way to check whether an autonomous system actually owns the address space it advertises. Any AS can announce any prefix. Neighbors mostly accept it. That’s not a footnote; it’s the entire security model, and it’s the reason every incident below is really the same incident wearing different clothes.
The interesting thing about BGP hijacks is not that they happen. It’s that they’ve been happening in exactly the same shape for over twenty-five years, and the arc runs from “oops” to “on purpose.”
The accidents
The genre opens with an accident. On April 25, 1997, a small provider running AS7007 took a big pile of routes it had learned, chopped them into tiny /24 fragments, and re-announced them as if it were the best path to all of them. Because a more specific route wins, traffic for huge parts of the internet started pouring toward a router that could not possibly handle it. Chunks of the network went dark. It was a misconfiguration — a fat-finger amplified by a protocol with no immune system — and it became the canonical example of how one network’s mistake becomes everyone’s outage.
For the next decade, that’s mostly what hijacks were: accidents. Someone leaks a routing table, someone announces a prefix they meant to keep internal, someone’s filter is missing. Pakistan/YouTube in 2008 was a censorship order that escaped containment. In April 2010, China Telecom carried a large set of routes it shouldn’t have — figures at the time claimed it briefly affected around 15% of the internet’s prefixes, though how much traffic actually detoured through China is disputed to this day and was almost certainly far smaller than the scary headline. The pattern held anyway: no malice required, just a missing filter and a protocol that trusts by default.
The weaponization
Then people noticed you could aim it.
The clean pivot is April 2018. Attackers didn’t go after a company — they went after Amazon’s Route 53 DNS service. Someone announced Amazon’s DNS address ranges from a network that had no business advertising them, and for a couple of hours, DNS queries meant for Route 53 were answered by the attacker instead. The target was MyEtherWallet. Users who typed the real address got a real-looking site served from hijacked infrastructure, complete with a self-signed certificate warning most of them clicked through, and roughly $150,000 in Ethereum walked out the door. The route hijack was just the delivery mechanism; DNS and a phishing page did the rest.
The state of the art arrived in Seoul on February 3, 2022. The KLAYswap heist is the one I’d hand to anyone who still thinks BGP is an infrastructure-team problem and not a security problem. The attackers didn’t touch KLAYswap’s servers. They hijacked the routes for a server that KLAYswap’s site loaded a JavaScript file from — a software development kit hosted by KakaoTalk. With that traffic redirected, they served a modified version of the SDK: same file, extra code bolted onto the end. When a KLAYswap user started a transaction in their browser, the injected script quietly redirected the assets to the attackers’ wallets.
It was surgical. The malicious file only went to people who arrived via KLAYswap — the attackers checked the HTTP referrer and served everyone else a harmless error, which kept the operation quiet. In about two hours, 407 fraudulent transactions drained roughly $1.9 million from 325 wallets, laundered through cross-chain bridges before most people knew anything was wrong. A supply-chain attack, executed by lying about a route.
That’s the arc in three moves: an accident in 1997, censorship spillover in 2008, and a precision financial weapon by 2022. Same missing feature every time.
We do have a fix. It’s optional.
The maddening part is that a defense exists. RPKI — Resource Public Key Infrastructure — lets an address block’s owner publish a signed record, a Route Origin Authorization, that says “only this AS is allowed to originate these prefixes.” Networks that do Route Origin Validation can then reject announcements that don’t match. It would have stopped a good chunk of the incidents above cold, because most of them are origin hijacks: the wrong AS claiming to be the source.
Adoption is real but half-finished. By late 2024, somewhere around 53% of IPv4 prefixes had valid ROAs, covering roughly 70% of traffic. That’s genuine progress from the near-zero of a decade ago, and large networks dropping invalid routes is why some modern leaks fizzle instead of spreading. But “half” means the other half is still naked, and there’s a nastier catch: RPKI validates the origin of a route, not the path it claims to take. An attacker who forges a plausible AS path can still slip past origin validation. RPKI raises the floor; it doesn’t close the hole.
So the honest summary is uncomfortable. We have known the failure mode since 1997. We have watched it graduate from clumsy accident to million-dollar heist. We built a cryptographic fix, standardized it, and then made deploying it a choice each network gets to make for itself — which is exactly the opt-in, trust-your-neighbor posture that created the problem. BGP hijacking isn’t an unsolved research question. It’s a solved problem we’re rolling out slowly, one signed record at a time, while the attacks get better faster than the defenses get deployed.
The next big one is already written. We just don’t know whose routes it’ll borrow.