BGP hijacking incidents are rising as RPKI adoption still lags where it matters
By mid-2026, 67.43% of announced internet routes had valid Route Origin Authorizations, and 70.3% of global traffic was flowing over RPKI-valid paths. On the surface, that's a genuine infrastructure win: Resource Public Key Infrastructure, the cryptographic system designed to stop networks from falsely claiming ownership of IP address blocks, has gone from a niche best practice to majority adoption in less than a decade. And yet Qrator Labs counted seven route leaks and at least one significant BGP hijack in the first quarter of 2026 alone, and network operators report seeing more than 6,000 RPKI-invalid prefixes announced on any given day. Adoption is up. Incidents haven't gone away. Those two facts aren't actually a contradiction, and understanding why matters for anyone running infrastructure that depends on the internet's routing layer behaving honestly.
What RPKI actually fixes — and what it doesn't
Border Gateway Protocol, the system that lets networks announce "I own this block of IP addresses, route traffic for it through me," was built in an era that assumed good faith between operators. It has no built-in authentication: any network can announce ownership of any address block, and neighboring networks generally accept the announcement unless something catches their eye. RPKI fixes the most basic version of this problem — a network cryptographically signs a Route Origin Authorization (ROA) proving it's authorized to announce a specific prefix, and other networks can validate that signature before accepting the route.
What RPKI's basic ROA validation does not fix is path forgery combined with more-specific announcements. This is the mechanism behind most of the incidents still happening on ostensibly well-protected networks in 2026: an attacker forges the origin AS number to match a legitimate ROA, then announces a sub-prefix more specific than the legitimate one. BGP's path-selection algorithm prefers more-specific routes almost unconditionally — it's a core, decades-old design principle, not a bug — so the forged, illegitimate announcement wins the routing decision even on networks doing textbook Route Origin Validation (ROV). The ROA checks out. The prefix is just wrong in a way ROV alone doesn't catch.
Why the fix for this is stalling
The technical answer to forged-origin sub-prefix hijacking exists: Autonomous System Provider Authorization (ASPA), a newer RPKI object that lets a network cryptographically declare its legitimate upstream providers, closing off a category of path-forgery attacks that ROA-only validation can't touch. The problem is deployment: as of mid-2026, ASPA objects cover only about 2.54% of autonomous systems globally. It requires every network in a path to participate for the protection to be meaningful, which makes it a classic coordination problem — any individual network gets limited benefit from deploying ASPA until enough of its neighbors do too, so adoption crawls even though the technology itself is mature and standardized.
There's also a simpler, less technical reason incidents persist: RPKI-invalid announcements at the scale of 6,000+ prefixes a day mostly aren't caught by malicious attackers testing sophisticated forged-origin techniques — they're misconfigurations, typos, and stale ROAs from operators who set up RPKI once and never revisited it as their network changed. Those routine errors create exactly the kind of background noise that makes it harder to spot the smaller number of genuinely malicious hijacks mixed in.
What this means for anyone running production infrastructure
If your organization peers directly with upstream providers or runs its own AS, Route Origin Validation is table stakes at this point — deploying it is no longer a hard sell, and most major transit providers now support it natively. But treat ROV as a floor, not a ceiling. Monitor your own prefixes for unauthorized more-specific announcements using a route-monitoring service (several offer free tiers for this specifically), since a forged-origin sub-prefix hijack against your address space will pass ROV validation cleanly and won't trigger the alerts most teams assume are already covering them. And if you're evaluating a transit or cloud provider partly on network resilience, ask specifically whether they've deployed ASPA — at under 3% global coverage, a "yes" is still a genuine differentiator, not a checkbox everyone can claim.