The route checked out. It was still a forgery.

Standfirst. Over two nights in late August, someone announced a block of Hetzner address space they did not hold. That much comes from the victims. What we can add is the part nobody in the coverage has looked at: the routing paperwork. The hijacked announcement was not missing a signature. It carried one — the right one, the real one, the block holder's own — and that is why it worked.

Figures with a dotted underline belong to their sources — Softaculous, whose own disclosure is this brief's peg, and webhosting.today, whose independent reconstruction we read for corroboration; both read 2026-09-01. No number on this page divides one of our instruments by the other.

Rung zero: what the wire actually recorded

The victims' account is short and specific. A block — 162.55.80.0/24, a portion of Hetzner's address space — was announced by a network their disclosure names, AS62390, reaching the internet through the transit provider AS6204. Certificate authorities validating domain ownership were routed through the hijack and issued certificates to it. A malicious update went out to Virtualizor installations. Softaculous published all of that themselves, promptly, with times; we take it as given and correct nothing in it.

Then we asked the routing repositories a question the coverage did not. We pulled RIPE's own record of the paths its collectors saw for that block during the window, and validated what was announced against the public route-origin database. In our snapshot window the collectors recorded 3,422 announcements of the block, seen by 276 RIPE peers. Every single one of those announcements carried the same origin: AS24940 — Hetzner's own number, the number that legitimately holds the block. That ASN is our own reading, not a figure from the disclosure: the victims' post names the attacker's network and its transit provider and stops there, and the forged origin is on every path in our snapshot. The announcing neighbour was the network the disclosure names, sitting one hop in front of an origin that was not its own.

There is exactly 1 published route object covering that block. It authorises Hetzner's ASN, at that length. So the hijacked announcement matched it. Under RFC 6811 — the standard that lets a router check whether the network announcing a block is allowed to — the state of the hijacked route was valid.

It is worth being precise about what that does and does not mean, because the obvious reading is the wrong one. Route origin validation was not absent here and it was not ignored. It ran, on however many of the world's routers run it, and it returned the answer the data told it to return. The block's owner had done the work: the object was published, current, and correctly scoped. The attack simply did not attack that. It borrowed the identity the object vouches for.

The counterfactual is instructive, and it is only a counterfactual. Had the same network announced the same block under its own number instead of forging the holder's, the published object would have contradicted it and the route would have been invalid — the state a validating router drops. That is the version of this attack the industry has spent a decade building for. It is not the version that happened. We publish that reading beside the real one and label it for what it is: counterfactual: had the attacker announced the prefix under its OWN origin ASN rather than forging the holder's, this is what a validator would have made of it — not what happened.

webhosting.today reconstructed the same window minute by minute from the collector data and reached compatible conclusions on the scale of the diversion: typically about 72 percent of RIPE's 368 routing vantage points were sending traffic for the block toward the attacker, peaking at 272 of them (73.9 percent); they count 10,600 withdrawals across the whole episode, put the total at about 22 hours over the two nights, and time the effective countermeasure at roughly 12 hours after onset. Their piece is about the propagation, not the routing repositories — which is the layer we went and read. Note that their vantage figures and ours are different measurements and are not compared: theirs is a propagation share of RIPE's whole collector fleet, ours is a count of the peers that saw the announcement at any point inside a much narrower window.

The ladder: published, enforced, aligned

Anyone who has worked on email authentication will recognise the shape of this immediately, because it is the same shape. A domain publishes SPF: here are the servers allowed to send my mail. A receiver enforces it: mail from anywhere else gets rejected. And then someone sends a message that passes SPF on a domain they do control, while the name in the From: header is yours — the authorisation checks out, and the identity it authorises is not the identity the reader sees. The answer to that is alignment, which is what DMARC adds.

Routing has the same three rungs and they were built in the same order. Published is the route object: this network may originate this block. Enforced is the router that actually drops what contradicts it. Aligned is the path: not merely is this origin allowed to announce this block, but is this neighbour allowed to be carrying it for that origin. The third rung has a name, ASPA, and it is where late August lands. Under a published ASPA for the block holder, the adjacency the hijack was carried on is one a path validator has an object to refuse. Without one, there is nothing to check the path against.

ASPA authorizes an AS's PROVIDERS so a validator can check the AS_PATH. RIS path history for the 2026-08-28 incident shows the hijacked announcement carried the prefix holder's own ASN as origin, so it was RPKI-valid under the holder's own ROA and route origin validation had nothing to drop. That is the forged-origin case ASPA addresses, and no ASPA was published for the origin it forged. Publication of an ASPA is still not enforcement of one: a published object only becomes a dropped route in somebody else's validator.

That is our routing instrument's own scope note, quoted verbatim rather than paraphrased, because it is the sentence the measurement is licensed by. One more thing rides with it everywhere ASPA appears below: the specification is draft-ietf-sidrops-aspa-profile-26 (IETF standards track, NOT yet an RFC). A low adoption number for a draft is a different finding from a low adoption number for a standard, and this brief never blurs the two.

The certificate layer sits downstream of this one. The late-August episode did not stop at misdirected packets: domain-ownership validation was itself routed through the diversion, so the attacker obtained genuine certificates and the poisoned update arrived over a connection that looked entirely ordinary. Any control the industry has that rests on "we checked who answered at that address" inherits whatever the routing layer decides — software update channels, certificate issuance, webhook callbacks, licence checks. That is a supply-chain exposure with a routing root cause, and it is not one a customer can fix.

Rung one: publication is largely done

We measure this on the address space the hosting industry announces for itself — the networks these companies actually operate, resolved through our own ownership authority, then checked announcement by announcement against the published route objects. The estate covers 167 operators.

Across the whole estate, 63.84% of announced IPv4 address space is covered by a matching published object — but a single announcer contributes 31% of that base and is nearly uncovered, so that figure is mostly a reading of one company. Excluding it, the estate reads 92.46%. That is the number we would put in a headline, and the excluded member is named in the method note below.

Counted by announcement rather than by address, the estate is at 76.91% — the two bases measure different things and both are published, always.

The interesting split is between the two ways of not being covered. 22.63% of announcements have no published object covering them at all — nobody has said anything about that space. Only 0.45% are contradicted by an object that does exist. Those are findings about different parties and we never add them together.

Underneath the estate average, the shape is bimodal rather than middling. Most operators have either finished this job or not started it.

Among the largest operators in the industry the spread is wide — from complete coverage down to around two-thirds of announced space. Both bases, because an operator can look finished on one and not the other: one large covered aggregate hides several small uncovered announcements.

The ten largest hosting groups in our book by active domains, ranked here by coverage. Both shares divide that operator's own announced space, which is the two right-hand columns. The ranking is presentation, not the finding: read this table as the same bimodal shape as the chart above, not as a league table of the big ten.

The operators who have finished

64 of the measured operators are at complete coverage on both bases at once — every announcement, and every address inside it, covered by a matching published object. That is the club worth being in, and it is not a club of giants: it runs from one of the largest hosting groups in Europe down to single-market operators with a few dozen announcements. Among the ones our registry has a name for: Hostinger, Hostpoint, Namespace, Tucows and ZXCS. A further 1 operator is complete by address but not by announcement, which is exactly the gap the second base exists to show — and is why we do not call that operator finished.

The full club is listed at the foot of this brief. Most of its members are identified by the technical key our measurement works from, because our operator registry carries no display name for them and we do not invent one; the table says so. The few that carry a company name there carry it on the same authority the pioneer table below uses — either the registry, or the company the operator's own network is registered to — so no operator appears on this page under two identities.

Rung two: enforcement, and why it is not the subject here

We do not measure this rung and will not pretend to. Whether a given network drops what its route objects contradict happens inside routers we neither run nor observe, and the honest thing to say about the industry's position on it is nothing. What the late-August episode settles is narrower and more useful: on this incident, that rung was not the one that failed. Nothing contradicted anything. A network with the strictest possible policy, dropping every invalid route it saw, would have carried this announcement exactly as its neighbours did — because under the published object it was not invalid. That is why the argument moves past enforcement rather than stopping at it.

Rung three: the pioneers

Nine companies in this book have a verified publication at the path layer, and Aruba has done it properly: 7 of its 9 own networks carry a published ASPA object. That is not one network with a token object on it — it is the great majority of a real estate, done deliberately, at a point in the standard's life when almost nobody has started. Here is the whole list, and every name on it is one we can stand behind.

Aruba, Miss Group, team.blue and your.online are all among the ten largest groups in our book. For the three besides Aruba it is one or two networks so far, which is what a first move inside a large estate looks like. Infomaniak reaches the list under two brand keys that are one company; we fold them, because a network is held by one company and crediting it twice would be a compliment nobody earned. The four operators our registry has no name for are named here by the company the network itself is registered to, which is the same evidence that credited them.

How we decided who to credit

Across the whole estate we resolve 417 networks that these operators own. Of those, 27 have a published ASPA object — 6.47%. In the entire public repository, across the whole internet and not merely this industry, there are 2,827 such objects. This is a draft specification with an early-adopter population, and the numbers should be read that way.

Which is exactly why the names above are worth being careful about. A network being in an operator's own set is not the same claim as that operator's company being the one that published the object: our ownership authority admits networks on announcement and hub evidence, which is a different question. So every pairing is put to a second test — does the registered holder of that network tie back to this operator, through the same identity machinery the rest of the platform uses? Of 28 operator/network pairs, 17 pass and 11 do not. The refusals are not one kind of thing, so we publish them as two. 2 of them name a third party outright — in those the network belongs to a transit carrier and to a national incumbent respectively, and crediting them would have handed a carrier's work to its customer. In the other 9 no authority ties the network's holder to the operator either way, which is a weaker finding and is still a reason not to credit: a credit is a claim that this company published this object, and an unresolved holder does not support one. After folding sibling brands onto one company, the credited work belongs to 9 operators across 16 networks.

And the incident-adjacent fact, stated plainly because leaving it out would be the more editorial choice: AS24940, the network whose identity was borrowed, publishes no ASPA. There is no criticism in that sentence. Almost nobody does; the specification is a draft; and publishing one is not the same as any router acting on it.

Why the gap persists

The first rung had a decade, a regional-registry campaign, and — decisively — a small number of very large transit networks that started dropping invalid routes, which turned publication from good citizenship into an operational necessity. Nothing equivalent has happened for the third rung yet. The specification is still a draft; validator support is young; and the object an operator would publish is a statement about its own upstreams, which changes whenever commercial arrangements do. A route object is written once for space you will hold for years. A path object is a live description of who you buy transit from.

The mail layer went through this exact sequence, and its numbers are the reason we recognise the shape. The parallel is structural, not arithmetic — two different books in two different units, and we compute nothing across them — so read the mail figures as a shape, never against the routing ones. On Europe's mail-carrying active domains, publication is close to universal — 82% publish SPF. Enforcement is much thinner: 29.2% ask receivers to reject what fails. And alignment, the rung that catches the identity swap rather than the unauthorised sender, is thinner still — 50.3% publish a DMARC record but only 9.6% publish a reject policy, over a base of 19,580,281 domains. What carries over is the order in which the industry does the work, and how long the last rung takes.

Why this costs money now

Diligence should be asking. Security posture is already on every infrastructure diligence list; routing posture rarely is. Yet in an infrastructure transaction, "does the target publish route objects for the space it announces" is an answerable question with a one-line answer, and it belongs beside the more familiar ones. Ours is a portfolio-level reading, per operator, on both bases, from public data — which means it is a question a buyer can put to a target and check independently rather than take on trust.

And for operators, the third rung is briefly a differentiator. Being one of the handful of companies in this book with a verified publication at the path layer is the kind of thing that stops being remarkable the moment it becomes common. The window in which it distinguishes you is open now and will not be open long — that has been the pattern on every rung of every one of these ladders.

Reproduce this — two instruments, two ways

The figures on this page come from two instruments and they reproduce differently, so it is worth being exact about which is which. The mail-side ones are served: they come out of the HostingBrain connector today, on the free tier. The routing ones are not in the connector at all — they come from public data, by the method described above, and you can re-derive them without us.

The routing figures come from public data anyone can recheck: the route-object and ASPA snapshots are a public validator export, the announced prefixes and the collector path history are RIPEstat data calls, and the hijacked block, the attacker's network and its transit provider are named in the victims' own disclosure. Every one of those sources is named in the method note above, with the window it was read over, so the derivation is repeatable from outside this company. The forged origin ASN is not in that disclosure — it is our reading of the collector data. The join — which networks belong to which hosting operator — is ours too.

Appendix: complete coverage on both bases

Every operator with complete ROA coverage by address space and by announcement at once, in order of announced space. Where our operator registry has no display name for an operator, the row says so and the technical key our measurement works from stands alone.