An RPKI-valid BGP hijack diverted Softaculous updates toward malware

28 August 2026, 20:57 UTC. A brand-new prefix, 162.55.80.0/24, enters the global routing table with a forged origin of AS24940 — Hetzner’s ASN. 30 August 2026. The prefix is withdrawn after roughly 33 hours of intermittent hijacking. 22 September 2026. Doug Madory (Kentik/Infoblox) publishes the full analysis in the APNIC Blog of what became the delivery of a malicious Virtualizor update through a fraudulent TLS certificate. Why it matters: the attack was RPKI-valid, which breaks the common assumption that origin validation alone stops a determined adversary.

Bypassing RPKI, in three ingredients

The attack leans on a well-known design weakness, exploited here with care. The attacker announced 162.55.80.0/24, a more-specific sub-prefix of the 162.55.0.0/16 legitimately announced by Hetzner (AS24940). The announced path ended with Hetzner’s ASN:

… 6204 62390 24940

This path is an origin forgery: the attacker appended 24940 on the right, making it look as if Hetzner is the origin. The route likely originated with NexonHost (AS62390), either through compromise or a customer abusing security gaps. Yet this route was RPKI-valid, for two reasons: Hetzner’s ROA required origin AS24940, and it allowed prefixes anywhere between /16 and /24. Because the /24 competed with no existing route, it was preferred over the legitimate /16 under longest-prefix-match: traffic destined for that range was redirected to the attacker.

The prefix “pulsed” several times: it appeared at 20:57 UTC on 28 August, stopped when Hetzner began announcing it at 08:44 UTC on 29 August, returned at 19:55 UTC, then was withdrawn for good around 05:45 UTC on 30 August.

The TLS certificate, the missing piece

The hijack alone was not enough. For clients to accept the update, the attacker had to serve content encrypted under a valid TLS certificate. The mechanism is the same as the 2022 attack against KLAYswap, documented by Henry Birge-Lee and his colleagues at Princeton: a BGP hijack first intercepts a certificate authority’s domain-validation requests to obtain a legitimate certificate.

Let’s Encrypt answered this risk with MPIC (Multi-Perspective Issuance Corroboration): domain control is validated from several geographically and topologically distinct vantage points, and a quorum must agree before issuance. But because the hijacked route was an uncontested more-specific prefix, its global propagation produced a quorum entirely controlled by the attacker. MPIC, designed to catch a localized hijack, was neutralized by a global one.

What it cost, and why it will happen again

Softaculous confirmed that a “technically valid TLS certificate”, combined with the hijack, allowed a malicious Virtualizor update to reach “a small number of installations”. The company urged customers to reset credentials and inspect their servers. This is not isolated: the same technique targeted Celer Bridge in 2022, and the author of the analysis notes that AWS used very permissive ROAs back then.

The technical lesson is clear. RPKI ROV (Route Origin Validation) meaningfully reduces routing mistakes and accidental leaks, but it is not designed to stop an adversary who forges their AS path. The real problem here is overly broad ROAs: a maxLength field left at /24 while only the /16 is routed creates a 9-bit gap in which a malicious sub-prefix can circulate. RFC 9319 recommends avoiding maxLength altogether and leaving the field blank — which is equivalent to an exact-prefix match.

Hetzner’s fix, and what it reveals

After the analysis was published, Hetzner corrected the ROA for 162.55.0.0/16, pulling its maxLength back to /16 and removing the possibility of an identical sub-prefix hijack in the future. The operator did the same for 213.133.96.0/19 and 213.239.192.0/18, which still allowed sub-prefixes down to /24.

But the fix is partial, and that is the most instructive point. Doug Madory notes that 50 of AS24940’s ROAs still show the same pattern after the correction: a block routed as a /16 whose ROA allows up to /24, a 9-bit gap ready to be exploited. A single organization, among the most structured in the industry, is still leaving dozens of openings of the same type in place. Hetzner also added an ASPA record listing its authorized upstreams, which lets networks that check it instantly reject a path whose upstream is unexpected — here AS62390.

This case illustrates the hierarchy of defenses. ROV reduces mistakes, strict ROAs remove the space where a malicious sub-prefix can circulate, ASPA locks down the authorized upstream, and BGP monitoring remains the net that catches what the first three let through. No single layer is enough: it is their combination that shrinks the window to the point where MPIC becomes effective again.

What to do

The response comes down to four measures, three of which are free and immediate.

• 1. Tighten your ROAs. Publish ROAs whose maxLength exactly matches the routed prefix, or leave the field blank. The maxLength gap is the exact attack surface exploited here.
• 2. Reject invalid routes. Deploy RPKI ROV and drop INVALID routes. It would not have been sufficient alone, but it reduces hijack propagation and handles accidental incidents.
• 3. Deploy ASPA. Hetzner added an ASPA record listing its authorized upstreams. Networks that check it instantly reject a path whose upstream is not on the list — here AS62390.
• 4. Monitor your prefixes. A BGP alert should have fired when a brand-new /24 of Hetzner appeared transiting exclusively through NexonHost. Monitoring the origin and upstream of your prefixes is the safety net that remains when everything else fails.

The incident also settles a long-running argument. For years, sub-prefix hijacks were dismissed as a niche threat aimed at cryptocurrency services, whose users had an obvious financial incentive to get their updates tampered with. Softaculous is different: it builds software for the web-hosting industry, and the payload was a control-panel update, not a crypto wallet. If an attacker will burn a 33-hour hijack to push a malicious Virtualizor build, the same playbook is worth running against any vendor whose updates travel over the public internet. It is a reminder that the routing layer, not the encryption layer, is where software supply-chain trust is actually established: a vendor that fixes its ROAs today is also fixing the trust story of every customer who updates tomorrow.

Verdict

If you announce address space on the internet, start by fixing your ROAs: an overly broad maxLength is an open invitation to a sub-prefix hijack, and it is precisely what made this attack possible. If you operate a service whose updates travel over HTTPS, do not take TLS for granted: a “valid” certificate proves nothing if the routing that issued it was hijacked — MPIC only protects against a localized hijack. If you rely on RPKI as your sole guardrail, this incident is the counter-example: forge the origin, and the route becomes valid. Resilience comes from combining strict ROAs + ROV + ASPA + BGP monitoring, not from any single building block.

References

• APNIC Blog — Latest BGP hijack targets hosting software vendor (22 September 2026)
• Kentik — Latest BGP Hijack Targets Hosting Software Vendor
• The Register — 33-hour BGP hijack of Softaculous traffic prompts security scramble (1 September 2026)
• MANRS — Latest BGP Hijack Targets Hosting Software Vendor
• Virtualizor — Security Incident: BGP Hijacking (update)
• Princeton CITP — Attackers exploit fundamental flaw in the web’s security to steal $2 million (2022)
• RFC 9319 — The Use of MaxLength in the Resource Public Key Infrastructure