An RPKI-Valid BGP Hijack: The maxLength Lesson from the Virtualizor Incident

In late August 2026, a block of IP addresses in Hetzner’s network was hijacked via BGP for roughly 33 hours. During that window, some traffic bound for the update servers of Virtualizor, a VPS control panel from Softaculous, was redirected to an attacker’s server, which then handed out an update package containing malware.

What makes this case worth studying is that the bogus route was RPKI valid. RPKI did not fail. The prefix holder’s ROA was simply too permissive. This article covers the basics, a short timeline of the incident, and a practical checklist to keep your own network from ending up in the same position.

BGP hijacking, briefly

BGP (Border Gateway Protocol) is how networks on the internet, each identified by an AS (Autonomous System) number, tell one another “you can reach this block of IPs through me.”

BGP largely takes those claims at face value. If an AS announces someone else’s prefix and its neighbours don’t filter it, the bogus route can spread. Routers also prefer the most specific route, so a /24 beats a /16 covering the same addresses. Announcing a small slice (a sub-prefix) of someone else’s block is therefore an effective way to pull traffic away.

RPKI, ROAs and ROV

RPKI (Resource Public Key Infrastructure) adds certificate-based checks:

• A ROA (Route Origin Authorization) is a signed statement from the prefix holder naming which AS may originate the prefix, plus a maxLength: the most specific prefix length that is still allowed.
• ROV (Route Origin Validation) is the router-side check of each announcement against ROAs. The result is Valid, Invalid or Not Found, and Invalid routes are usually dropped.

The key limitation: ROV checks only the origin AS, not the full AS path. The origin field in BGP is not signed, so an attacker can list the victim’s AS as the origin and insert their own AS as if it were the victim’s transit provider. This is known as a forged-origin hijack.

Why maxLength matters

RFC 9319 (BCP 185) gives an example. If the holder of 192.168.0.0/16 creates a ROA with maxLength 24, every /24 inside that block is considered legitimate as long as the origin matches, including /24s the holder never announces. An attacker only needs to announce one of those /24s with a forged origin, and the route passes ROV and wins on specificity. This is a forged-origin sub-prefix hijack.

With a “minimal” ROA, one that covers only the prefixes actually announced, that sub-prefix would be Invalid. An attacker could still try a forged origin on the same-length prefix, but that route has no automatic advantage, so the damage is much more limited.

RFC 9319 also cites 2017 measurements: about 12% of prefixes in ROAs used a maxLength longer than their own length, and about 84% of those were exposed to this kind of attack.

What happened in the Virtualizor incident

Based on the analyses by Ipregistry and everyWAN, both drawing on public RIPE RIS/RIPEstat data and the vendor’s incident report:

Item	Detail
Hijacked prefix	162.55.80.0/24, part of Hetzner’s (AS24940) 162.55.0.0/16
Announcing AS	AS62390, propagated through upstream AS6204
Window	28 August 2026 around 20:57 UTC to 30 August 2026 around 06:10 UTC (about 33 hours)
ROA at the time	162.55.0.0/16, origin AS24940, maxLength 24
RPKI status of the bogus route	Valid

In the observed paths, AS24940 still appeared as the origin, with AS62390 posing as Hetzner’s transit. Because the ROA allowed AS24940 to originate anything down to /24, routers running ROV accepted the route.

Other points from the sources:

• TLS certificates. About 33 minutes after the first announcement, a Let’s Encrypt certificate for the vendor’s domains showed up in Certificate Transparency logs. Ipregistry reports it covered 26 domain names, including virtualizor.com and softaculous.com, and has since been revoked. Users who connected to the impostor server would not have seen a certificate warning.
• Malicious update. According to the vendor, Virtualizor’s update client did not yet cryptographically verify packages. The vendor described the impact as “a handful of servers”; one hosting provider reported 5 of its 34 hypervisors compromised. There is no definitive list of affected installations.
• Recovery. Diversion stopped for a while after Hetzner announced the /24 itself, then the bogus route returned before finally disappearing. RIPEstat data cited by everyWAN shows Hetzner’s ROA maxLength changing from 24 to 16 in early September 2026. The holder has not published a reason for the change.

One nuance is easy to miss. everyWAN points out that Hetzner’s own emergency /24 announcement was only valid because of the maxLength 24. With a minimal ROA, that countermeasure would have required issuing a new ROA first. Being able to reissue ROAs quickly during an incident matters as much as the initial configuration. RFC 9319 also allows ROAs to be created in advance for prefixes you may genuinely originate for mitigation, such as DDoS scenarios.

For comparison: Telegram, June 2026

On 16 June 2026, AS18101 (Rcom) originated Telegram prefixes as its own. The cause is disputed. According to Anurag Bhatia’s write-up, Telegram’s prefixes were covered by ROAs, so networks running ROV rejected the routes, and the hijack spread through upstreams that did not filter Invalid routes.

The two cases complement each other. With Telegram, correct ROAs did their job, and the leak happened where ROV wasn’t enforced. With Virtualizor, ROV worked as designed, but a loose ROA made the bogus route look legitimate. RPKI is effective when both sides get it right: holders publish accurate ROAs, and transit networks enforce ROV.

Checklist for network operators and IP space holders

ROA configuration

1. Create a ROA for every prefix you actually announce, including any announced on your behalf by others.
2. Set maxLength equal to the announced prefix length, or leave it out. If you announce a /22 and two /23s, create three separate ROAs instead of one /22 ROA with maxLength 24.
3. Review your ROAs whenever routing policy changes, as RFC 9319 requires. APNIC likewise advises keeping maxLength no broader than necessary.
4. Prepare an emergency ROA procedure: who has access to the RIR or NIR portal, and how long changes take to propagate.

Enforcement and filtering

5. Enable ROV on your edge routers and drop Invalid routes.
6. Filter customer BGP sessions against ROAs and IRR route objects.
7. Ask your upstreams in writing whether they drop RPKI-invalid routes.
8. Consider ASPA, a newer RPKI object for validating AS relationships along the path. Ipregistry and APNIC both recommend it, though support across equipment and networks is still uneven.

Data and coordination

9. Register route objects in an IRR and keep contact details in routing databases current, in line with the MANRS actions.

Monitoring

10. Alert on more-specific announcements you didn’t make, unknown origins or upstreams, and ROA changes. Open-source tools such as BGPalerter use public BGP data for exactly this.

For software vendors

11. Sign update packages and verify signatures with a key that doesn’t travel over the same channel. This incident shows TLS alone is not enough once the route to your server is hijacked.

How Cloudku approaches this

Cloudku runs its own BGP network, AS133337, connected to the BIX, CXC and JKT-IX Internet Exchanges and monitored by a 24/7 NOC. Our prefixes are registered in an IRR, and our IPv4 prefixes are covered by RPKI ROAs.

If you hold your own IP space and want to announce it over a BGP session, Cloudku’s IP Transit and Colocation services are a good place to start. Make sure your ROAs and route objects match the prefixes you plan to announce before the session goes live. We also offer a set of free tools for everyday network tasks.