The route hijack RPKI called valid: the ROA allowed all the way down to /24

Between 20:57 UTC on 28 August 2026 and 06:10 UTC on the 30th, traffic bound for 256 IP addresses belonging to a hosting-panel vendor went somewhere else. No browser warned about anything, because the attacker obtained a legitimate TLS certificate for those domains. A handful of servers asked for an update, received a malicious package and installed it. And then there is the part that made us open a console: while it lasted, the hijacked route was valid under RPKI. Not invalid, not questionable: valid.

We run our own network: we announce our addresses over BGP and we have transit and peering. When we read the incident report, one word was missing, so we went looking for it ourselves. What follows is the reconstruction, the number that is not in the report, and the checks anyone can run today, with or without an autonomous system of their own.

What happened, with timestamps

At 20:57 UTC on 28 August, autonomous system AS62390 (NexonHost) began announcing the prefix 162.55.80.0/24 through transit provider AS6204 (Zet.net), declaring AS24940 as the origin —that is Hetzner, the legitimate holder of that space. The real block is announced as a /16.

And there is the BGP rule that decides the rest of the story: the more specific prefix wins. A /24 beats a /16 on any network that accepts the announcement, regardless of local preference, communities or AS path length. There is no tie to break: they are two different destinations and the router picks the more specific one.

The incident window ran for about 33 hours, but the diversion was not active throughout: it came in two waves adding up to roughly 22 hours, separated by an eleven-hour lull. And that lull was not luck. The vendor's timeline puts it like this: after reporting the hijack to Hetzner and escalating repeatedly, "Hetzner begins announcing 162.55.80.0/24 directly" and "diversion drops to zero within minutes". The mitigation that worked was de-aggregation: fighting for the more specific prefix with the same weapon. Keep that sentence in mind, because it comes back two sections down.

Measured across the 368 peers of RIPE's route collection system, at its peak roughly 72 % of them saw the bogus route; the time-weighted average was around 28 % of all peers, or 65 % counting only those carrying a route to that destination. All 368 carried it at some point, with some 10,600 withdrawals recorded. An example path from the report: 20912 6204 62390 24940. That last hop —the origin— is the only thing origin validation looks at, and it is a number the attacker typed in by hand.

The padlock does not say who you are: it says who answered

A certificate authority checks that you control a domain by connecting to it over the network. If the network lies, the check lies. The report says it plainly: the certificate authority's automated domain-ownership validation was also routed through the hijack. The result: a technically valid Let's Encrypt certificate for the vendor's own sites —the report's appendix lists every hostname covered— issued to the wrong party. No browser warning, no error in the client downloading updates.

Someone will ask about validation from multiple network vantage points. It exists: Let's Encrypt deployed it at scale in February 2020 and says it was the first CA to do so. It raises the bar and defeats local or short-range hijacks. But a route that most of the internet can see is also visible from the points doing the validating, and there the multiplicity stops helping. The report does not explain how that check was passed and we are not going to invent it; what is measured is how far the route travelled. It is the same lesson we wrote about the DNS hijack on hotel wifi: encryption protects the content of the path, it does not tell you whether the path is the right one.

The number that is not in the report

The missing word is RPKI. The incident report does not mention it once. RPKI is the system by which the holder of a block of addresses signs an object —a ROA— stating "this prefix may be originated by this autonomous system, down to this length". Routers doing origin validation drop whatever does not match. So we went to look at what the ROA for that block actually said.

Queried on 5 September 2026, RIPEstat replies that today this /24 is invalid by length: the ROA for 162.55.0.0/16 authorises AS24940 with maxLength 16. You can reproduce it in one line:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS24940&prefix=162.55.80.0/24" | jq .data.status
# returns: "invalid_length"
curl -s "https://stat.ripe.net/data/rpki-history/data.json?resource=162.55.0.0/16" | jq -r '.data.timeseries[] | [.time, .max_length] | @tsv'
# 2026-08-28  24   <- the day of the hijack# 2026-09-01  24# 2026-09-02  16   <- two days later

The history is the interesting part. From the earliest data RIPEstat keeps, 17 March 2021, until 1 September 2026, that ROA carried maxLength 24. On 2 September it changed to 16. In other words: the value changed two days after the hijack ended, and throughout the 33 hours it lasted it stood at 24.

Let us be honest about what we do not know: nobody has stated why the ROA was tightened on 2 September. The timing is there for anyone to check; the reason has not been published by the holder and we are not going to publish it on their behalf.

RPKI validates the origin, not the path

Origin validation answers exactly one question: is the autonomous system at the end of the path authorised to originate this prefix? That solves human error —the classic wrong announcement at three in the morning— and clumsy hijacks. It does not solve someone who forges the origin, because the origin AS is a field in the announcement, not a signature: you write whatever you like in it.

And if on top of that you leave a maxLength wider than what you actually announce, you are handing the forger an authorised sub-prefix: precisely the piece that wins route selection. This is not our hunch. It is written in RFC 9319 (BCP 185, October 2022), titled The Use of maxLength in the Resource Public Key Infrastructure (RPKI), and the wording is explicit: "In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal". The same document reports a June 2017 measurement: 12 % of the prefixes authorised in ROAs carried a maxLength longer than their own prefix length and, of those, 84 % were exposed to a forged-origin sub-prefix hijack.

The uncomfortable part: that maxLength was also the cure

Here is that sentence again. What stopped the diversion was the legitimate holder announcing the /24 itself. And that emergency announcement was only RPKI valid because the maxLength stood at 24. With a minimal ROA —maxLength 16, the one in place today and the one the RFC recommends— Hetzner's countermeasure would have come out invalid by length, dropped by exactly the networks that do their homework best.

That tension is real and RFC 9319 acknowledges it: operators issuing minimal ROAs have to change them in order to change what they originate, and it still concludes that the minimal ROA offers the best possible protection against the immediate impact of such an attack. We agree, with one operational condition almost nobody writes down: if you narrow the maxLength, you need to be able to reissue the ROA live —at three in the morning, without hunting for whoever has the RIR portal password. The minimal ROA is the right posture; the agility to change it is what makes it safe. Without the second, you have simply swapped one risk for another.

The piece that would fully close the path hole —validating that whoever propagates an announcement is entitled to do so, not just who claims to originate it— is still being standardised and deployment remains marginal. In the meantime, the realistic defence rests on two things: leaving no authorised sub-prefixes lying around, and not trusting the network for anything that truly matters.

What this means if you do not run your own AS

If your company does not speak BGP, you cannot stop someone hijacking your provider's prefix. What you do control is what happens at your end when it occurs. And what happened here is that some servers requested an update over a flawless encrypted channel and installed a package nobody had signed. The encryption authenticated the server name; nothing authenticated the content.

The vendor has announced it will implement code signing for all its packages. That is the right conclusion, and it is the question you should be putting to anyone allowed to install software on your machines without your involvement —starting with the remote management agent, which we have already argued is an attack surface in its own right.

The indicator of compromise the vendor published is a systemd unit: /etc/systemd/system/java-jre-update.service. A plausible name, in a normal place, with every appearance of having come from a legitimate update process. No network layer sees that; the host's own telemetry does. That is the practical difference between an antivirus that looks at files and an EDR/MDR service that looks at what gets created, executed and persisted.

Six checks you can run today

What we do with this

At everyWAN we run our own network: BGP announcements, transit and peering, plus the habit of checking how our routes look from outside before somebody else tells us. When we set up a customer's own address space —described in detail in multihoming with your own IP and two ISPs— the ROA goes into the deliverable with the exact length announced, and with the name of whoever can change it at three in the morning.

And in the consulting that comes first, half the job is writing the list above before it is needed: who signs your routes, who can install software on your machines without asking you, and who looks at the box when the warning arrives in English on the blog of a vendor you did not know you had.

For the twenty-two hours that announcement was live, anyone running the checks got a correct answer: the origin was authorised, the certificate was valid and the update arrived as served. All three said yes, and none of the three was checking the thing that mattered.

Sources: hijack timeline (28 August 2026 at 20:57 UTC to the 30th at 06:10 UTC: a window of about 33 hours, two waves adding up to some 22 hours of active diversion, and an eleven-hour lull that begins when Hetzner, after the report and repeated escalation, starts announcing the /24 directly and diversion drops to zero within minutes), prefix 162.55.80.0/24, AS62390 (NexonHost) announcing via transit AS6204 (Zet.net) with declared origin AS24940, propagation measured across 368 RIPE RIS peers (peak ~72 %, time-weighted average ~28 % of all peers and ~65 % of route-carrying peers, ~10,600 withdrawals), Let's Encrypt certificate valid for the vendor hostnames listed in the report's appendix, delivery of a malicious update package to a small number of installations, indicator /etc/systemd/system/java-jre-update.service and recommended actions (rotate API keys, restrict access by IP, review SSH keys, accounts and scheduled tasks, reset client-area passwords, future code signing): public incident report published by Virtualizor/Softaculous. Status and history of the ROA for 162.55.0.0/16 (origin AS24940; maxLength 24 from 17 March 2021 to 1 September 2026 and 16 from 2 September; the /24's invalid_length status today): queries to RIPEstat's public API made on 5 September 2026, reproducible with the commands in the article. The maxLength quotation ("In general, operators SHOULD avoid using the maxLength attribute in their ROAs, since its inclusion will usually make the ROA non-minimal"), the June 2017 measurement (12 % of prefixes authorised in ROAs carried a maxLength longer than their own length; of those, 84 % were exposed) and the acknowledgement that issuing minimal ROAs means changing them in order to change what you originate: RFC 9319 / BCP 185, "The Use of maxLength in the Resource Public Key Infrastructure (RPKI)", October 2022. The RFC itself allows for exceptions, among them announcing for real every more specific the maxLength permits. Deployment of multi-vantage-point validation in February 2020: Let's Encrypt's blog. What we do not claim: we do not know why the ROA was tightened on 2 September —the holder has not said— and the report does not explain how the certificate authority's validation was passed; the connection we draw between route propagation and that validation is our reasoning, not a published fact.