A BGP Hijack Against Softaculous: How a Forged Route Yielded a Valid TLS Certificate

Just days ago, Softaculous Ltd — the vendor behind the Softaculous auto-installer and the Virtualizor VM management platform — was hit by an attack built on a Border Gateway Protocol (BGP) hijack. The company says an attacker used a “technically valid TLS certificate” together with the hijack to deliver a “malicious Virtualizor update package” to a “small number of installations,” and has published steps for customers to check whether they were affected.

How the address space was hijacked

At 20:57 UTC on 28 August 2026, a new prefix appeared in the global routing table: 162.55.80.0/24. It covered the IPs of Softaculous’s update endpoint as well as its client and billing site. This was a more-specific hijack of 162.55.0.0/16, normally originated by Hetzner Online (AS24940). The route most likely came from the penultimate AS in the path — the little-known provider NexonHost (AS62390) — through either a compromise or a customer exploiting gaps in its security.

The crucial trick: the attacker appended AS24940 as the rightmost ASN, forging the origin. That made the route RPKI-valid, because the ROA required origin AS24940 and allowed prefix lengths from /24 up to /16. As a more-specific route, it beat the legitimate /16 under longest-prefix-match and pulled traffic in. The real Hetzner repeatedly intervened by announcing the /24 itself, but the hijack kept returning.

Where the valid certificate came from

The hijack alone wasn’t enough. The same weakness was exploited in the 2022 attack on South Korean crypto exchange KLAYswap: the flaw isn’t in TLS itself, but in the false trust TLS places in routing. By intercepting traffic, the attacker ran a man-in-the-middle attack on domain-control validation and obtained a genuine certificate.

To counter this, Let’s Encrypt has for years used Multi-Perspective Issuance Corroboration (MPIC): domain control is checked from geographically and topologically diverse locations, and a quorum must agree. Here, though, the hijacked route propagated so widely and uncontested that the entire quorum fell under the attacker’s control.

What would have helped

The author stresses that strict ROAs — where the maximum prefix length matches what is actually routed — would have sharply narrowed the window, likely letting MPIC block issuance. BGP monitoring would also have helped: a new Hetzner /24 transited exclusively through the obscure NexonHost should have raised a flag.

After publication, Hetzner tightened the ROA for 162.55.0.0/16 to maxLength /16 and fixed two other blocks. Still, roughly 50 of AS24940’s ROAs retain the old, loose configuration. Hetzner also added an ASPA record listing its authorized providers — networks that check ASPA can now immediately reject routes carrying an unexpected upstream such as AS62390.

Source: Lobsters