BGP hijack plus fake TLS certificate hit Softaculous

A BGP hijack was used to help attack a hosting software vendor. BGP, the Border Gateway Protocol, is the system that lets networks on the internet tell each other which blocks of addresses they can reach. Softaculous Ltd, the company behind the Softaculous auto-installer and the Virtualizor platform for managing virtual machines (software versions of a computer that run on a physical server), has described how an attacker combined such a hijack with a technically valid TLS certificate to deliver a malicious Virtualizor update package to a small number of installations. The company advised customers to follow a sequence of steps to check whether they were affected. The technical analysis is by Doug Madory, Head of Internet Analysis at Infoblox, and was originally published on the Kentik blog.

How the hijack took the addresses

At 20:57 UTC on 28 August 2026 a new prefix entered the global routing table. A prefix is a block of internet addresses written in shorthand; this one, 162.55.80.0/24, covered addresses used by Softaculous's software update endpoint as well as its client and billing site. It was announced along an AS path reading ? 6204 62390 24940. An AS path is the list of networks a route passes through, written as numbers called Autonomous System Numbers (ASNs). The announcement was a more specific piece of the larger block 162.55.0.0/16, which is normally originated by Hetzner Online (AS24940). The route likely originated with the second-to-last network in the path, NexonHost (AS62390), either because that network was compromised or because a customer took advantage of gaps in its security.

Why it looked legitimate

The path also carried a forged origin. By appending 24940 as the rightmost number, the attacker made the route appear RPKI-valid. RPKI, the Resource Public Key Infrastructure, is a system of signed records stating which network is allowed to announce which addresses. The route passed for two reasons: Hetzner's Route Origin Authorization (ROA, the signed record itself) required AS24940 as the origin, and it allowed the prefix length to be anywhere between /24 and /16. Networks that reject RPKI-invalid routes therefore had no reason to drop it. Because no other route for 162.55.80.0/24 existed to compete with it, the announcement spread as far as filtering policies allowed. Routers always prefer the most specific match available, so traffic meant for that address range was pulled to the hijacked route instead of following the real 162.55.0.0/16.

How long it lasted

Kentik's BGP visualization, which shows the share of BGP vantage points (independent observation points around the internet) that had 162.55.80.0/24 in their routing tables over time, traces the timeline. From the moment the route first appeared at 20:57 UTC on 28 August, it pulsed on and off several times until the real AS24940 began announcing the prefix itself nearly 12 hours later, at 08:44 UTC on 29 August. By 14:10 UTC the next day AS24940 had withdrawn it again. The hijack returned at 19:55 UTC on 29 August and pulsed repeatedly until AS24940 intervened once more, announcing 162.55.80.0/24 at 05:45 UTC on 30 August, at which point the hijack was withdrawn. At the time of writing AS24940 was still announcing the prefix. The chart shows the hijacked route propagating slightly less widely than the legitimate one, evidence that some route filtering limited it, but the propagation was still substantial and created the potential for widespread misdirection of traffic.

Why a routing hijack alone was not enough

The attacker also needed a valid TLS certificate. TLS is the encryption that protects a connection and also proves the identity of a website. The same weakness was exploited in the 2022 attack on KLAYswap, an online cryptocurrency exchange in South Korea. In their post on that incident, Henry Birge-Lee and his colleagues at Princeton wrote that KLAYswap and Kakao were properly using TLS and that no flaw in the TLS protocol itself was exploited; instead the attack abused the false trust that TLS places in the routing infrastructure. The adversary first aimed its hijack at the PKI (public key infrastructure, the system of certificate authorities that issue certificates) and ran a man-in-the-middle attack on the certificate distribution process. Only after obtaining a valid digital certificate for the target domain did it turn to real users, serving a malicious JavaScript file over an encrypted connection. Their post was titled "Attackers exploit fundamental flaw in the web's security to steal $2 million in cryptocurrency".

TLS's identity guarantee is only as trustworthy as the routing system that carries certificate validation traffic to the right place. To address this, the public certificate authority Let's Encrypt has used Multi-Perspective Issuance Corroboration (MPIC) for several years. Under MPIC, a certificate authority does not validate control of a domain from a single vantage point, which a localized BGP hijack can spoof. It checks from several geographically and topologically diverse network locations at the same time and requires a quorum to agree before a certificate is issued, so a hijack that reaches only some vantage points is caught by disagreement among the others. In this case, because the hijack route was an uncontested more specific route, its global propagation created a quorum entirely controlled by the attacker.

What earlier incidents showed

In 2022 a BGP hijack also targeted Celer Bridge, a cryptocurrency service hosted by AWS. In the post Madory wrote at the time, he cited AWS's then practice of using very liberal ROAs, which allowed multiple origins and prefixes ranging in size from a /10 all the way down to a /24, as a factor that limited RPKI Route Origin Validation's ability to help. He suggested an alternative: do what networks such as Cloudflare and Comcast have done and set the origin and maximum prefix length to match exactly how the prefix is routed. That approach costs the overhead of updating a ROA every time a route changes, but it leaves little room for alternate versions of a route to circulate. AWS now does exact matches on its ROAs.

Madory is careful not to oversell RPKI Route Origin Validation (ROV), the practice of checking routes against signed records, as a defence against a determined adversary. Attackers can forge AS paths to make hijacks RPKI-valid. Even so, had Hetzner Online used strict ROAs with maximum prefix lengths that matched its routes, the circulation of the hijack would have been greatly diminished, which in turn would have allowed MPIC to prevent the issuance of a valid TLS certificate.

Detection would also have been possible. As with the Celer Bridge attack, BGP monitoring could have alerted Hetzner that a new /24 of its address space was being announced, although the forged origin might have made it look legitimate. When that new /24 appeared with an unexpected upstream, NexonH