Seventy percent of routed prefixes on the internet are now RPKI valid, and the biggest hijack of the year passed validation anyway. IPinfo published its yearly RPKI numbers on October 15. On September 28 it counted 1,614,288 routed prefixes, and 70.3% of them matched a signed Route Origin Authorization. A year earlier the figure was 54.0%. The two years before that gained 3.9 and 3.2 points. This year gained 16.4.

That jump has one main cause. China.

Measured by IPv4 addresses rather than prefixes, China went from 3.7% covered in September 2025 to 83.0% in September 2026. IPinfo says China accounts for almost 60% of the global gain by address count. Take China out and the rest of the world moved from 58.0% to 63.2%, which is a normal year. Egypt went from 23% to 99%, Kazakhstan from 16% to 84%, Mexico from 37% to 78%, South Africa from 38% to 60%. A handful of large carriers and registries made those decisions. Thousands of small networks did not each wake up and do the right thing.

The laggard is the United States. Nearly 60% of routed IPv4 space that sits outside a valid ROA is American, and about one in four of those unprotected addresses belongs to the Department of Defense, mostly space it started announcing in 2021 so it could watch for abuse. If you run a US network and your prefixes still show "not found" in a validator, you are the reason the global number isn't higher.

RPKI does one job. An address holder signs a record that says these prefixes may be announced by this autonomous system, down to this prefix length. Routers that validate compare each BGP announcement against those records and drop the ones that fail. An invalid route now reaches a median of two vantage points, against 596 for a valid route. In practice a bad origin announcement goes almost nowhere.

It does not check the path. If an attacker announces your prefix with your ASN at the end of the path, the origin check passes. And if your ROA says a /16 may be announced at any length down to /24, the attacker can announce a /24 inside it, keep your ASN as the origin, and win on longest prefix against your own /16 everywhere on the internet.

That is exactly what happened to Hetzner on August 28.

33 hours, one setting

At 20:57 UTC on August 28, AS62390 (NexonHost, in Romania) announced 162.55.80.0/24 with a forged path ending in AS24940, Hetzner's ASN. Transit provider AS6204 passed it on. Within the first minute the route reached 584 route collector peers. Hetzner's ROA covered 162.55.0.0/16 with maxLength 24, so the announcement validated as RPKI valid. BGPKIT's reconstruction from 79 collectors shows diversion peaking at 615 peers about three hours in.

The /24 hosted update and billing servers for Softaculous, the company that makes Virtualizor, a hypervisor control panel used by small hosting providers. Thirty-three minutes after the first announcement, a Let's Encrypt certificate covering 26 Softaculous and Virtualizor names appeared in certificate transparency logs. The attacker answered the domain validation challenge from an impostor box at 162.55.80.8. Let's Encrypt checks from multiple network vantage points, but when the whole internet prefers your route, every vantage point lands on you.

With a valid certificate, the attacker served a fake Virtualizor update advertising version 3.2.9.8. Hypervisors that polled during the hijack got a package that installed Java 17, dropped a jar in /tmp, registered a systemd unit, added an ed25519 key to root's authorized_keys, and created a user named proxyuser. The update client did not verify package signatures. Virtualizor said so in its disclosure: "Our product update clients did not yet cryptographically verify update packages." AlbaHost, one affected provider, found modifications on 5 of its 34 hypervisor nodes. Virtualizor says it cannot produce a full list of victims because the malicious responses never touched its logs.

Hetzner announced its own /24 about 12 hours in, which cleared the diversion within minutes. Then it withdrew that /24 around 14:30 UTC on August 29, and five hours later the hijack came back for a second wave of about ten hours. The whole thing ended around 06:10 UTC on August 30. Doug Madory at Kentik wrote up the hijack. The short version is that one ROA setting at a hosting provider handed an attacker root on other people's hypervisors.

By September 3, validators showed Hetzner's ROA for that block reissued with maxLength 16. With that record in place, the forged /24 validates as invalid and validating networks drop it. The fix was a change to one field, and RFC 9319 has recommended it since 2022: leave maxLength unset and sign exactly what you announce.

Sixteen percent of signed routes have the same hole

IPinfo went looking for how common Hetzner's configuration is. Of the 855,217 IPv4 routes covered by RPKI, 138,698 have a ROA looser than the route itself with no more specific announcement filling the gap. That is 16.2% of signed IPv4 routes and 20.9% of IPv6. Roughly 18 million more specific prefixes are sitting there, already authorized for anyone who can forge an origin.

Hosting providers are the worst offenders, which should bother anyone who rents servers:

  • Contabo: 540 of 553 covered routes open
  • DigitalOcean: 780 of 863 covered routes open
  • OVH: 11.5% of covered routes open
  • Hetzner, after the fix: 49 of 63 covered routes still open

Access networks are no better. Cablevision has 98.1% of its covered routes open, Shaw 96.5%, Bharti Airtel 85.0%. Each of those is a Hetzner incident waiting for a motivated attacker and a target worth the trouble.

I understand why people set maxLength. You sign the /16 once, and you can carve /24s out of it for years without touching the RPKI portal again. It feels like good hygiene. It is the opposite. A ROA with maxLength 24 is a signed statement that any /24 in the block is legitimate, and the signature is yours.

ROAs also rot

The report has a section on protection that disappeared. SEACOM lost four of its six ROAs on January 1, and 105.16.0.0/12, about one million addresses, still had no ROA at the end of September. Saudi Telecom lost coverage on 19 routes, including six large blocks totaling about 1.6 million addresses, between March 30 and April 13. The records came back on September 21. Orange Maroc lost most of its ROAs twice, once for a full year and once for six weeks this summer, which dropped Morocco from 20% covered to almost nothing and back. Mauritius fell from 94% to 69% because of a single missing record.

Nobody attacked these networks. A certificate expired, or the one person who knew the portal login left. A ROA is a thing you have to monitor the way you monitor a TLS certificate, and most networks don't. If you publish ROAs and nothing alerts you when they vanish, you have a protection that works until the day you need it.

Path validation has barely started

The structural fix for the Hetzner attack is ASPA, which lets a network publish the list of providers allowed to carry its routes. A path of 6204 62390 24940 fails the moment Hetzner publishes a record naming Deutsche Telekom and its other upstreams. A Romanian host nobody has heard of is not on that list. Hetzner had no ASPA record. Neither did anyone else in the path, and BGPKIT found 2,820 ASPA objects in the entire global export at the time.

The numbers are moving. ASPA publishers went from 131 networks on September 28, 2025 to 3,272 a year later. The share of observed routing that passes an ASPA check went from 6.2% to 9.7%, but about 6 points of that is short paths that pass automatically. Strip those out and published records verify about 3.5% of routing, up from 0.1%. Most of the remainder reads "unknown" because too few networks on the path have published anything.

And the records people do publish are often wrong. Of the 3,272 publishers, 479 have upstreams visible in routing data that their ASPA record omits. Syrian Telecom lists four carriers, three of which carry 16% of its transit and one of which carries none. The four that handle the other 84% are missing. That one network accounts for 21% of all ASPA failures in the middle of a path anywhere on the internet. PCCW, the transit that spread the 2008 YouTube hijack, has no ASPA record of its own, and nearly 6,000 paths through it fail because downstream networks forgot to list it.

Seventy percent is a milestone, eighteen years after Pakistan Telecom took YouTube off the internet for two hours. Origin validation is the default now and a bad origin goes nowhere. But the attackers have read the spec too. The Hetzner hijack was RPKI valid, got a certificate from a public CA, and shipped a backdoor as a software update. A tighter ROA and an ASPA record on Hetzner's side would have stopped it, and so would a signed update package on Virtualizor's side. All of that sits with operators, and none of it is hard. The 16.2% of loose ROAs is the number I'll check next year. My guess is it drops by less than three points, and we read about another hijack that passed validation before it does.