When RPKI Says 'Valid' But It's a Hijack: The maxLength Loophole

Imagine a school office issuing permission slips. A careful slip says, “Aisha may leave campus on Friday.” A lazy slip says, “Any student may leave campus on any Friday this year.” Both carry the principal’s real signature. Both validate. But the lazy one authorizes almost anything.

A loose maxLength in a Route Origin Authorization works like that lazy slip. It is officially signed and can produce an officially Valid result, yet still leave room for a forged route.

What actually happened on August 28, 2026

At about 20:57 UTC on August 28, an unauthorized route for 162.55.80.0/24 appeared on the internet. That range held Softaculous infrastructure, including endpoints used by its Virtualizor server-management software.

The route arrived through AS62390 (NexonHost) and transit AS6204 (Zet.net). Its AS path ended with AS24940, Hetzner’s real ASN and the legitimate origin for the covering 162.55.0.0/16. Routers prefer a more-specific route: a /24 describes fewer addresses than a /16, so traffic from routers that learned both went toward the attacker’s server.

The diversion came in two waves and ended around 06:10 UTC on August 30. The route flapped heavily between announcements; Virtualizor reported about 10,600 withdrawals. Yet Route Origin Validation, or ROV, classified the forged route as RPKI Valid. Hetzner’s ROA for the /16 allowed announcements down to /24.

The attacker then obtained a technically valid Let’s Encrypt TLS certificate for affected domains. Multi-perspective validation did not save the situation: there was no legitimate competing /24, and the forged route spread widely. Virtualizor reported that all 368 peers in its RIPE RIS sample carried the route at some point. During active waves, the median was 266 diverted peers—about 72%. HTTPS clients saw no certificate warning. Virtualizor’s update clients did not yet cryptographically verify downloaded packages, so a malicious update reached a small number of installations.

What maxLength actually is

A ROA is a signed statement published in RPKI through the prefix holder’s RIR, or Regional Internet Registry. It says: “Prefix P may be originated by AS X.” The maxLength field sets the longest, most-specific prefix length covered by that permission.

A ROA for 162.55.0.0/16 with maxLength 16 authorizes only the /16. Set maxLength to 24 and the same ROA authorizes the /16 plus every /24 inside it—256 possible more-specific prefixes the owner may never have announced.

Try it: would YOUR ROA stop this?

Change the authorization or announcement below. The widget performs the same three route-origin checks a validator uses.

Why “Valid” is not proof of legitimacy

ROV, specified by RFC 6811, checks only three facts: whether a covering ROA exists, whether the announced length is within maxLength, and whether the origin ASN matches. It never validates the rest of the AS path. Nobody checked whether the hop through AS62390 and AS6204 was legitimate. APNIC’s incident analysis describes this exact failure mode, and it sits within the RFC’s stated limits.

The attack crossed three trust boundaries. First, routing delivered clients to the wrong endpoint. Second, certificate validation followed that hijacked route; broad diversion defeated multi-perspective checks, so TLS looked normal. Third, the update client trusted the protected channel instead of verifying the downloaded package. Each layer assumed the previous one had done enough.

The incident timeline, annotated

How operators lock down their ROAs

1. Tighten maxLength to what you actually announce. If you announce a /16 as a /16, authorize /16—not /24. An exact-length ROA would have made the forged /24 Invalid at every ROV-enforcing network. APNIC reported that Hetzner later tightened this ROA to /16 and found roughly 50 other Hetzner ROAs authorizing more-specifics that were not being announced; that count is a snapshot from the published analysis. If you need more-specifics for traffic engineering, DDoS mitigation, or emergency counter-announcements, create explicit ROAs before changing BGP policy. Hetzner’s own defensive /24 needed a matching ROA. Keep a playbook naming who can publish an emergency ROA, how validators are checked, and when the route is announced and withdrawn. RFC 9319 discusses minimal ROAs and mitigation more-specifics.
2. Filter customer announcements at your edge. A transit provider should verify what each customer is authorized to announce. Do not accept an unexpected more-specific simply because its origin validates. Max-prefix limits contain mistakes; they do not prove ownership. First-AS enforcement alone would not have stopped this attack: the neighbor can place its own ASN first while leaving the forged origin last.
3. Validate the path, not just the origin. ASPA, or Autonomous System Provider Authorization, lets an AS publish its authorized upstreams. Routers can then test adjacent AS pairs. Hetzner published an ASPA for AS24940 after the incident; AS62390 is absent. At AS6204, learning the route from customer AS62390, ASPA validation could have stopped it at the first transit hop. ASPA path verification was still an IETF draft, revision 28, in August 2026. Check support in your validators and routers, but publishing an accurate ASPA for your AS costs little.
4. Monitor from outside your network. Alert on a previously unseen more-specific plus an unexpected upstream AS plus sightings across independent BGP collectors. Do not require continuous visibility: this route flapped about 10,600 times.
5. Limit certificate issuance and watch the logs. Use CAA records, including account binding and validation-method restrictions where appropriate. Monitor Certificate Transparency logs for surprise certificates on production and update domains.
6. Verify the code, not just the channel. Update clients should verify a vendor signature with a trusted key the server cannot silently replace. Then a hijacked endpoint and valid TLS certificate still cannot install attacker code. Softaculous v6.4.1, released September 21, added RSA/SHA-256 package verification. Virtualizor’s advisory described package signing as work in progress.

Check your own ROAs today

Use the BGP Toolkit—especially its RPKI Check and Hijack Verdict tabs—to see how ROV classifies announcements, then audit every maxLength in your RIR portal. No single control eliminates this risk. Tight ROAs, customer-edge filtering, path awareness, package signatures, and outside monitoring form the defense in depth.