Recent cybersecurity incidents continue to underscore the fragile dependency of modern internet infrastructure on underlying routing protocols that were designed decades ago without security in mind. Just days ago, a malicious Border Gateway Protocol (BGP) hijack targeted hosting software vendor Softaculous Ltd, the developer behind the widely used Softaculous auto-installer and the Virtualizor virtual machine management platform.
In a detailed technical disclosure published by the company, Softaculous explained that an unknown adversary orchestrated a carefully planned attack combining a BGP routing hijack with a technically valid Transport Layer Security (TLS) certificate. This combination allowed the attackers to successfully deliver a malicious Virtualizor update package to a small, targeted number of installations. Following the discovery, the vendor advised its customer base to execute specific verification steps to determine whether their systems had been compromised during the window of exposure.
The incident highlights a recurring and fundamental vulnerability in how the global web establishes trust. By manipulating internet routing tables, sophisticated actors can subvert cryptographic verification mechanisms, creating severe risks for software supply chains and digital infrastructure worldwide.
How did the attacker hijack this IP space?
The malicious activity began unfolding late in the evening on August 28, 2026. At precisely 20:57 UTC, an anomalous prefix entered the global routing table. The address range 162.55.80.0/24 was abruptly announced along a specific Autonomous System path that wound through several network operators.
This specific address block included critical infrastructure IP addresses utilized by Softaculous for its software update distribution endpoint, as well as its primary client and billing web portals. Rather than a random network disruption, this was a more specific prefix hijack targeting the broader 162.55.0.0/16 address block normally originated by hosting provider Hetzner Online, which operates under Autonomous System Number AS24940.
Network routing analysis indicates that the rogue route likely originated from the penultimate Autonomous System in the advertised path, NexonHost, operating as AS62390. This could have occurred either through the direct compromise of the hosting provider’s infrastructure or by exploiting security gaps left open by a customer permitted to announce prefixes through their network.
A critical element of the attack involved manipulating the AS path to include a forged origin. By deliberately appending the legitimate origin number 24940 as the rightmost Autonomous System Number in the path vector, the malicious announcement managed to appear valid under the Resource Public Key Infrastructure validation framework. This occurred because the corresponding Route Origin Authorization permitted the prefix length to span anywhere between a /16 and a /24 block. Consequently, the route was classified as RPKI-valid, shielding it from being automatically dropped by network operators who maintain strict policies against invalid routes.
Because no legitimate competing route for 162.55.80.0/24 existed in the global routing tables at the time, the announcement propagated across the internet as far as neighboring route-filtering policies permitted. Under standard internet routing behavior governed by longest-prefix-match rules, this more specific prefix took precedence over the legitimate 162.55.0.0/16 route. As a result, traffic destined for those specific Softaculous endpoints was surreptitiously redirected straight into the attacker’s controlled infrastructure.
Visibility data compiled through BGP monitoring tools illustrated the intermittent nature of the attack. From its initial appearance on August 28, the rogue route pulsed on and off repeatedly over the span of several hours. The legitimate network operator, Hetzner Online, eventually intervened by announcing the correct routing information nearly twelve hours later, prompting the withdrawal of the malicious announcement. However, the unauthorized route reappeared briefly the following day before being definitively countered and withdrawn as network operators applied corrective measures.
How did the attacker get a valid TLS certificate?
While the BGP hijack successfully redirected victim traffic toward the attacker’s infrastructure, it represented only half of the strategy. A secondary, highly critical component of the operation involved obtaining a cryptographically valid TLS certificate for the targeted domains. This technique mirrors the methodology observed in high-profile historical incidents, such as the 2022 attack against the South Korean cryptocurrency exchange KLAYswap.
Security researchers examining past infrastructure attacks have frequently pointed out a fundamental paradox in modern web security: services often utilize TLS correctly, yet remain vulnerable because the underlying cryptographic validation frameworks place blind trust in the global routing infrastructure. By executing a localized BGP hijack first, an adversary can effectively mount a man-in-the-middle attack on the digital certificate validation process itself. Only after successfully tricking certificate authorities into issuing a valid digital certificate for the target domain will the attacker direct their efforts toward end-users by serving malicious code over an ostensibly secure, encrypted connection.
The identity guarantees provided by TLS protocols are ultimately only as reliable as the routing systems responsible for delivering certificate validation traffic to its intended destination. To mitigate this systemic weakness, major public certificate authorities—most notably Let’s Encrypt—have widely adopted Multi-Perspective Issuance Corroboration.
Under an MPIC framework, instead of relying on a single network vantage point to validate domain control—which can easily be spoofed via a localized routing hijack—the certificate authority verifies validation requests simultaneously from multiple geographically and topologically diverse network locations. Issuance is granted only if a broad quorum of these independent vantage points agrees on the validation response. A localized routing manipulation that reaches only a fraction of these vantage points will typically fail when other locations report conflicting observations.
However, the Softaculous incident bypassed this safeguard due to the unique nature of the routing manipulation. Because the attacker announced an uncontested, more specific prefix that achieved widespread global propagation, they effectively created a localized routing consensus entirely controlled by their own infrastructure, satisfying the multi-perspective checks from the perspective of the deceived validation servers.
Prevention and detection strategies for infrastructure security
The mechanics of this attack mirror earlier compromises targeting high-value internet services, such as the 2022 routing hijack directed against the Celer Bridge platform hosted on Amazon Web Services. In that earlier instance, security analysts highlighted the risks associated with overly permissive Route Origin Authorizations that allowed multiple origins and wide ranges of prefix sizes, severely limiting the defensive utility of Route Origin Validation.
While major cloud providers and network operators have since tightened their ROA configurations to enforce exact prefix matches, security experts caution against overestimating the ability of RPKI validation to completely fend off determined adversaries. It has long been recognized that sophisticated attackers can forge AS paths to bypass basic validation checks. Nevertheless, had the upstream network operators employed strict ROAs with maximum prefix lengths precisely matching their allocated routes, the widespread circulation of the hijacked prefix would have been severely constrained, allowing multi-perspective certificate validation defenses to function as intended.
Continuous BGP monitoring would have alerted administrators that a new /24 address block within their allocation was suddenly being announced, though the forged origin could initially masquerade as legitimate activity. The critical anomaly that should have drawn immediate suspicion was the unexpected upstream provider appearing in the path announcement, combined with the rapid and pervasive global propagation of a prefix controlled by a relatively minor hosting provider.
While RPKI validation has dramatically reduced the frequency of accidental routing mishaps and simple leaks across the global internet, it was never architected to serve as a standalone defense against targeted, malicious infrastructure subversion. Stricter configuration practices and rigorous administrative oversight remain essential components of a defense-in-depth posture.
Following the public disclosure of the incident, network operators have begun taking corrective steps to close lingering vulnerabilities. Updates applied to core routing records have successfully restricted maximum prefix lengths, effectively eliminating the possibility of identical sub-prefix hijacks across similar address spaces in the future. Furthermore, the adoption of emerging technologies such as Autonomous System Provider Authorization records will increasingly empower automated networks to instantly reject unauthorized routing paths, shrinking the window of opportunity for threat actors attempting to subvert critical internet infrastructure.
Leave a Reply