Latest BGP Hijack Targets Hosting Software Vendor
Summary
This post analyzes the technical details of the BGP hijack against Softaculous Ltd, the company behind the Softaculous auto-installer and the Virtualizor VM management platform. The hijack enabled an attacker to fraudulently obtain a TLS certificate and use it to deliver a malicious Virtualizor update to a portion of the company’s customer base.
Just days ago, a BGP hijack was used as part of an attack on hosting software vendor Softaculous Ltd, the company behind the Softaculous auto-installer and the Virtualizor VM management platform. In a blog post on the incident, the company explains that an attacker used a “technically valid TLS certificate” for their domains, in concert with a BGP hijack, to deliver a “malicious Virtualizor update package” to a “small number of installations.” They advise customers to follow a sequence of steps to check if they have been impacted.
What follows is a closer look at some of the technical details of this incident.
How did the attacker hijack this IP space?
Beginning at 20:57 UTC on August 28, 2026, a new prefix entered the global routing table. 162.55.80.0/24 was announced along the AS path:
… 6204 62390 24940This address range included IP addresses used for Softaculous’s software update endpoint as well as its client and billing site. It was a more-specific hijack of the 162.55.0.0/16 normally originated by Hetzner Online (AS24940). The route likely originated with the penultimate AS in the path, NexonHost (AS62390), either through a compromise or a customer who took advantage of gaps in their security.
The hijack also included an AS path with a forged origin. Because the attacker appended 24940 as the rightmost ASN in the path, it was considered RPKI-valid for two reasons: the ROA required the origin to be AS24940 but also because it allowed the prefix length to be anywhere between 24 and 16. As a result, this route was RPKI-valid and would not be at risk of being dropped by ASes that reject RPKI-invalid routes.
Because there was no existing route for 162.55.80.0/24 to compete against, it propagated as far as other route filtering mechanisms would allow. And because it was a more-specific route, any traffic destined for this IP range would prefer it over the legitimate route (162.55.0.0/16) due to routers’ preference for longest-prefix-match.
The timeline of the origination of 162.55.80.0/24 is depicted in Kentik’s BGP visualization below. The graphic depicts the percentage of BGP vantage points that had 162.55.80.0/24 in their routing tables over time and can be interpreted as a measure of route propagation.
The visualization helps to illustrate the timeline of the presence of 162.55.80.0/24 in the global routing table. From the time it first emerged at 20:57 UTC on August 28, the route pulsed on and off several times until the real AS24940 began announcing it nearly 12 hours later, at 08:44 UTC on August 29. By 14:10 UTC the next day, AS24940 had withdrawn its route.
The hijack route returned at 19:55 UTC on August 29 and pulsed repeatedly until, once again, the real AS24940 intervened and began announcing 162.55.80.0/24 at 05:45 UTC on August 30, at which time the hijack was withdrawn. At the time of this writing, AS24940 is still announcing 162.55.80.0/24.
As the visualization above depicts, the propagation of the hijack route was slightly lower than that of the legitimate route, so there was some route filtering happening that limited further propagation. Regardless, the hijack propagation was substantial and created the potential for widespread misdirection of traffic to 162.55.80.0/24.
How did the attacker get a valid TLS certificate?
The BGP hijack alone wasn’t enough to pull off this attack. Another critical piece to the puzzle is the issuance of valid TLS certificates to the attacker. The same flaw was exploited in the 2022 attack against KLAYswap, an online cryptocurrency exchange based in South Korea.
In their excellent post on that incident, Henry Birge-Lee and his colleagues at Princeton wrote,
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.
TLS’s identity guarantee is only as trustworthy as the routing system that gets certificate validation traffic to the right place. To address this weakness, public certificate authority Let’s Encrypt has been doing Multi-Perspective Issuance Corroboration (MPIC) for several years.
In MPIC, instead of a CA validating domain control from a single vantage point (which a localized BGP hijack can spoof), the CA checks from multiple geographically and topologically diverse network locations simultaneously and requires a quorum to agree before issuing a certificate. A hijack that only reaches some vantage points gets caught by disagreement among the others.
However, in this case, because the hijack route was an uncontested more-specific, its global propagation created a quorum entirely controlled by the attacker.
Prevention and detection
Also in 2022, a BGP hijack successfully targeted the cryptocurrency service Celer Bridge, hosted by AWS. In the post I wrote at the time, I cited AWS’s then practice of using very liberal ROAs that allowed multiple origins and prefixes “ranging in size from a /10 all the way down to a /24” as a factor that limited RPKI ROV’s ability to help. In that post, I added,
An alternative approach to ROA creation would be to do what other networks such as Cloudflare and Comcast have done: set the origin and maximum prefix length to be identical to how the prefix is routed. While this approach incurs an overhead cost of updating an ROA every time a route is modified, it also leaves little room for alternate versions of the route to come into circulation.
AWS now does exact matches on its ROAs, but let’s be careful not to oversell the capabilities of RPKI ROV to save us from a “determined adversary” such as this. We’ve always known that attackers can forge AS paths to render hijacks RPKI-valid. But had Hetzner Online used strict ROAs with maximum prefix lengths that matched its routes, the circulation of the hijack would have been greatly diminished allowing MPIC to prevent the issuance of valid TLS certificates.
As was the case with the Celer Bridge attack, BGP monitoring could have alerted that a new /24 of Hetzner Online address space was being announced, although the forged origin may have caused it to appear legitimate.
But when this new /24 appeared with an unexpected upstream of NexonHost (AS62390), an alert should have drawn attention to this anomaly. The key detail here that would have distinguished this alert from the appearance of just another peer of Hetzner Online would have been that the new upstream was seen by the vast majority of BGP vantage points. In other words, this new prefix was getting exclusively transited by this relatively unknown hosting provider, and that could have caught the eye of the Hetzner Online NetOps team.
Conclusion
While RPKI ROV has meaningfully contributed to the reduction of routing mishaps, it is not designed to completely prevent an incident like this one. It works by reducing the propagation of leaked mis-originations, typically involving innocent mistakes. We’ve also seen the benefits of RPK ROV during so-called “intentional, but also accidental” hijacks, such as the blocking of Telegram in India back in June. Regardless, stricter ROAs could have allowed RPKI ROV to reduce the propagation of the hijacked route to the extent that MPIC could have prevented the issuance of a valid TLS certificate.
The infrastructure attacks like these highlight universal problems that aren’t restricted to cryptocurrencies or hosting software. Companies looking to secure their internet-facing infrastructures need to deploy robust BGP and DNS monitoring of their infrastructure and any internet-based dependencies they may have.
Companies should reject RPKI-invalid routes while creating strict ROAs for their IP address space by including maximum prefix lengths that match the prefix lengths used in their routes. In fact, RFC 9319 The Use of maxLength in the Resource Public Key Infrastructure (RPKI) states that it is a “best current practice” that networks entirely avoid using the maxLength attribute in ROAs, except in certain circumstances. Leaving the maxLength field blank in a ROA has the same effect as setting the maxLength field to match the prefix. These steps can significantly reduce the window of opportunity for an attacker to subvert your internet infrastructure.
