BGP Hijack Against Hosting Vendor Exploited Routing and Certificate Validation Gaps

A hosting software vendor named Softaculous Ltd, which develops the Softaculous auto-installer and Virtualizor VM management platform, fell victim to a coordinated attack involving routing manipulation and certificate fraud. The attacker leveraged a BGP hijack alongside a "technically valid TLS certificate" to push a "malicious Virtualizor update package" to a limited set of customer installations. Softaculous published guidance for affected users to determine whether their deployments were compromised.

How did the attacker hijack this IP space?

Starting at 20:57 UTC on 28 August 2026, an unauthorized prefix announcement entered the global routing table. The prefix 162.55.80.0/24 was announced with an AS path that included AS 6204, AS 62390, and AS 24940. This address block contained IP addresses serving Softaculous's update distribution, client portal, and billing infrastructure. The hijack targeted a more specific subset of the 162.55.0.0/16 range, which Hetzner Online (AS24940) legitimately originates.

The attacker constructed the AS path to appear valid under RPKI standards by appending AS24940 as the final Autonomous System Number. This satisfied two conditions: the Route Origin Authorization required AS24940 as the origin, and the ROA permitted prefix lengths between /24 and /16. Consequently, the hijacked route passed RPKI validation checks and would not be filtered by networks enforcing RPKI Route Origin Validation.

Because no competing announcement existed for 162.55.80.0/24, the hijacked route propagated widely through the Internet. Under longest-prefix-match routing logic, the more specific /24 took precedence over the legitimate /16, redirecting traffic destined for those addresses toward the attacker's infrastructure.

BGP visualization data from Kentik showed the hijacked prefix cycling on and off multiple times. The announcement first appeared at 20:57 UTC on 28 August, then pulsed intermittently until Hetzner Online began announcing the legitimate route nearly 12 hours later at 08:44 UTC on 29 August. By 14:10 UTC that day, Hetzner withdrew its announcement. The hijack reappeared at 19:55 UTC on 29 August and continued pulsing until Hetzner intervened again at 05:45 UTC on 30 August. At the time of reporting, AS24940 remained the active originator of 162.55.80.0/24.

The hijacked route achieved substantial propagation across BGP vantage points, though slightly lower than the legitimate route, indicating some filtering mechanisms were in place. Nevertheless, the reach was sufficient to create a significant risk of widespread traffic misdirection.

How did the attacker get a valid TLS certificate?

The BGP hijack alone could not have succeeded without the acquisition of legitimate TLS certificates. This attack pattern mirrors a 2022 incident targeting KLAYswap, a South Korean cryptocurrency exchange. Researchers at Princeton documented how the attackers exploited a fundamental weakness in the web's security model.

Yet, ironically, KLAYswap and Kakao were properly using TLS, and it was not a vulnerability in the TLS protocol that was exploited during the attack. Instead, the attack exploited the false trust that TLS places in the routing infrastructure. … Using its BGP hijack, the adversary first targeted the PKI and launched a man-in-the-middle attack on the certificate distribution process. Only after it had acquired a valid digital certificate for the target domain did it aim its attack towards real users by serving its malicious JavaScript file over an encrypted connection.

Henry Birge-Lee and colleagues at Princeton

TLS certificates derive their security guarantees from the routing system's ability to direct certificate validation requests to legitimate servers. To counter this vulnerability, Let's Encrypt has implemented Multi-Perspective Issuance Corroboration (MPIC) for several years. Under MPIC, a Certificate Authority validates domain control from multiple geographically and topologically dispersed network vantage points simultaneously, requiring consensus before issuing a certificate. A localized BGP hijack that reaches only some vantage points will be detected when other perspectives disagree.

In this case, however, the hijack route's global propagation as an uncontested more specific prefix meant the attacker controlled a quorum of validation vantage points, allowing fraudulent certificate issuance to proceed.

Prevention and detection

A similar BGP hijack in 2022 targeted Celer Bridge, a cryptocurrency service hosted on AWS. AWS's routing authorization practices at that time permitted multiple origins and prefix lengths ranging from /10 down to /24, which limited RPKI Route Origin Validation's effectiveness. A more restrictive approach, adopted by networks including Cloudflare and Comcast, sets both the origin and maximum prefix length to match the actual routes in use. While this requires updating ROAs whenever routes change, it prevents alternate route versions from circulating.

AWS has since shifted to exact-match ROAs, though RPKI ROV cannot fully protect against determined adversaries capable of forging AS paths. Had Hetzner Online enforced strict Route Origin Authorizations with maximum prefix lengths matching its actual routes, the hijack's propagation would have been severely constrained, potentially allowing MPIC to block fraudulent certificate issuance.

BGP monitoring systems could have detected the announcement of a new /24 within Hetzner Online's address space, though the forged origin might have made it appear legitimate. However, when the /24 appeared with an unexpected upstream provider, NexonHost (AS62390), an alert should have triggered. The distinguishing factor would have been that this new upstream was visible to the vast majority of BGP vantage points globally, meaning a relatively obscure hosting provider was exclusively transiting this prefix—an anomaly that should have caught the attention of Hetzner Online's network operations team.

Conclusion

RPKI ROV has reduced routing mishaps but was not designed to prevent incidents of this sophistication. It primarily mitigates leaked mis-originations caused by innocent mistakes and has proven useful in blocking accidental hijacks, such as the Telegram blocking in India in June. Stricter ROAs could have limited the hijack's propagation enough for MPIC to prevent fraudulent certificate issuance.

These infrastructure attacks demonstrate problems that extend beyond cryptocurrency and hosting services. Organizations protecting Internet-facing systems should deploy comprehensive BGP and DNS monitoring for their own infrastructure and external dependencies.

Best practices include rejecting RPKI-invalid routes and creating strict ROAs for IP address space by setting maximum prefix lengths to match actual routing practices. RFC 9319, The Use of MaxLength in the Resource Public Key Infrastructure, designates this as best current practice and recommends avoiding the maxLength attribute in ROAs except in specific circumstances. Leaving maxLength blank produces the same effect as setting it equal to the prefix length. These measures substantially reduce the window for attackers to compromise Internet infrastructure.

Update

Following this analysis, Hetzner modified the ROA for 162.55.0.0/16 to set maxLength to /16, eliminating the possibility of similar sub-prefix attacks. The company applied the same restriction to ROAs for 213.133.96.0/19 and 213.239.192.0/18, tightening maxLength from /24 to /19 and /18 respectively.

Despite these corrections, 50 of AS24940's remaining ROAs continue to exhibit the same vulnerability pattern. For example, 78.46.0.0/15 is routed as a /15 but the ROA permits /24, creating a nine-level gap. Most /16 blocks similarly allow /24 when only the /16 itself is routed. The tightening applied to three ROAs appears incomplete, with the maxLength issue persisting across most of Hetzner's address space.

Bryton Herdes of Cloudflare noted that Hetzner Online added an ASPA record listing authorized upstream providers for AS24940. Networks checking ASPA records can now immediately reject routes with AS_PATH entries including unauthorized upstreams, such as AS62390 in this attack.