Softaculous Hit by 33-Hour BGP Hijack, Urged to Reset Credentials

It has been revealed that Softaculous, a developer of software for the hosting industry, and Virtualizor, the virtualization management panel it provides, suffered a BGP hijack lasting 33 hours. The company is urging customers to reset credentials and check for suspicious packages on their servers. According to reporting by Connor Jones of The Register, attackers spoofed routing information and diverted some traffic to their own servers.

This incident differs in nature from attacks that exploit a single vulnerability in that it abused internet routing itself. The fact that intervention at the infrastructure layer made it possible to obtain legitimate certificates shows that the chain of trust operators have taken for granted can collapse.

Timeline of the 33-Hour Route Hijack

According to Softaculous, the first anomaly occurred around 20:57 UTC on August 28, 2026. An unrelated network began fraudulently announcing routes for Hetzner’s IP address blocks used by Softaculous. Hetzner is a hosting provider based in Germany that provides upstream infrastructure for Softaculous.

The affected addresses were used by multiple systems, including Virtualizor’s software update endpoints and Softaculous’s customer and billing sites. The attackers announced more-specific (longer-prefix) IP ranges than those normally announced by Hetzner. Because BGP routing prefers more-specific routes, traffic on networks that accepted the announcements was diverted to the attackers.

According to the company’s timeline, the fraudulent routes were initially “accepted at almost every observation point on the internet that received them.” However, they were not continuously maintained and repeatedly exhibited unstable behavior.

a number of Softaculous systems

Softaculous reported the issue to Hetzner around 08:50 UTC on August 29. Hetzner countered by announcing the same more-specific address ranges itself, suppressing the diversion to almost zero for about 11 hours. However, around 20:00 UTC that same day, the fraudulent announcements were again widely accepted, beginning a second wave that lasted about 10 hours. The fraudulent routes were withdrawn between 05:50 and 06:10 UTC on August 30, after which normal routing was restored globally.

Hijacking Technique Using More-Specific Routes

This technique is a classic route hijack rooted in BGP specifications. The attackers announced routes that were more narrowly subdivided than the aggregated routes announced by the legitimate operator. Routers on the internet determine forwarding destinations by longest-prefix match, so the more specific routes take precedence. For this reason, within the scope where the attackers’ announcements propagated without being filtered, legitimate traffic destined for Softaculous was directed to the attackers’ servers.

According to Softaculous, while either wave was ongoing, the probability that a given server would be drawn into the attackers’ routes is estimated to have reached about 72 percent. This figure is an estimate based on route acceptance at each observation point, and not all users were uniformly affected. The unstable fluctuation of the routes is also seen as a factor that caused variation in impact.

This type of attack does not require a sophisticated vulnerability. Because BGP itself was not originally equipped with a mechanism to strictly validate the legitimacy of routing information, even erroneous announcements will propagate if not rejected by recipients. In recent years, countermeasures such as Route Origin Validation using RPKI (Resource Public Key Infrastructure) have advanced, but adoption and operation are still in progress.

Impact of Fraudulent TLS Certificate Acquisition

Notably, the attackers succeeded in obtaining legitimate TLS certificates from Let’s Encrypt. According to The Register, automated validation communications for domain ownership verification by the certificate authority were also diverted to the attackers’ servers via the hijack, allowing the verification to pass.

As a result, on affected connections, the attackers’ servers were able to present legitimate certificates. Browsers and update clients did not display certificate warnings, depriving users of an opportunity to notice the anomaly. The combination of route hijacking and fraudulent certificate acquisition significantly increased the difficulty of detection.

This issue highlights that domain validation depends on the integrity of network routes. Validation using DNS or HTTP carries the risk that the validator itself will communicate with the attacker if routes are hijacked. Mitigations such as multi-perspective validation, which verifies from multiple vantage points, are being introduced, but their effectiveness may be limited when fraudulent routes are accepted at a wide range of observation points, as in this case.

Scope of Damage and Vendor-Requested Response

Softaculous has confirmed that malware was delivered in a small number of installations. While details about the specific malware type and post-infection behavior have not been disclosed, the company is asking all customers to reset credentials and scrutinize suspicious packages on their servers.

Virtualizor is a control panel used to deploy and manage virtual private servers and is widely used by hosting providers and administrators. If update endpoints are hijacked, malicious code disguised as legitimate updates could be distributed. The fact that Softaculous’s customer and billing sites were also affected increases the risk of exposure of credentials and payment information.

The company is proceeding to notify potentially affected customers while urging server-side integrity checks. Specifically, it calls for hash verification of installed packages, auditing of recently modified files, reissuing passwords and API keys for privileged accounts, and checking for suspicious outbound communications. Even when considering restoration from backups, care must be taken not to reintroduce backups from a compromised state.

As a long-term challenge regarding infrastructure trust, as pointed out in Microsoft Secure Boot Remained Vulnerable for 13 Years, there is a risk that legitimate mechanisms will continue to operate for long periods without sufficient validation. This BGP hijack can also be seen as the result of the long-standing absence of route validation.

Structural Vulnerabilities in BGP

BGP is a routing protocol designed in the 1980s that assumes the exchange of routing information between mutually trusting networks. It was not originally designed to anticipate malicious announcements and has no cryptographic function to guarantee route legitimacy. As a result, there remains room for erroneous announcements and intentional hijacks to propagate globally.

Countermeasures such as ROA (Route Origin Authorization) validation via RPKI, route signature validation via BGPsec, and filtering based on IRR databases have been proposed and implemented. If a major operator like Hetzner registers ROAs and enforces strict validation upstream, fraudulent announcements of more-specific routes like those in this incident would be more likely to be rejected. However, if even a single network that has not enabled validation relays the route, the impact can still spread.

In addition, Certificate Transparency and monitoring of CT logs could also help with early detection of fraudulent issuance like this. Because Let’s Encrypt certificates are recorded in CT logs, owners who monitor them can detect unexpected issuance. Combined with route monitoring services, operations that correlate anomalous announcements with certificate issuance are also conceivable.

Operational and Validation Challenges for

Preventing Recurrence

In this incident, Hetzner temporarily contained the damage by announcing the same more-specific routes itself. While effective as a symptomatic treatment, this method is not a fundamental solution. If it escalates into a competition where attackers announce even more specific routes, it could lead to bloat and instability in routing tables. A lasting solution lies in widely deploying rejection based on validation.

For hosting providers and software vendors, protecting the update infrastructure is also an urgent issue. Designs that do not rely on a single route or single validation method for communications with update servers are required. For example, mandating signing of update packages and signature verification on the client side can prevent execution of malicious code even if routes are hijacked. Certificate pinning and reachability checks via multiple paths can also serve as effective additional layers.

On the user side, it is difficult to individually detect a wide-area hijack like this. A realistic response is to utilize integrity verification tools provided by vendors and external monitoring information. For the industry as a whole, sharing route monitoring data and establishing rapid coordination systems for anomaly detection are becoming increasingly important. Even as application integration progresses, as seen in Microsoft Announces App Integration Toward Copilot Unification, improvements in convenience and ensuring security at the infrastructure layer must be balanced.

There are also increasing cases where disputes over intellectual property and contracts affect trust in the technology infrastructure. As shown by Round Hill Sues Suno and Anthropic for Over $1 Billion, service continuity depends not only on technology but also on legal and institutional factors. Route security must also be supported by both technical measures and operational policies.

Editorial Opinion

In the short term, we expect moves to strengthen authenticity verification for update servers to spread across the hosting industry. Users of Softaculous and Virtualizor will be forced to reset credentials and verify packages over the next few months. We assess that vendors will also urgently enforce signed updates and introduce CT log monitoring. Upstream providers including Hetzner are expected to review stricter RPKI validation and filtering of more-specific routes.

In the long term, we believe pressure on BGP’s trust model itself will intensify. RPKI and multi-perspective validation are still being adopted, and the fact that fraudulent routes were accepted at a wide range of observation points in this case shows that partial deployment is insufficient. We expect that within one to three years, operations predicated on route validation will become the industry standard. For users, whether an update infrastructure assumes signature verification is likely to become a criterion for service selection.

As a question from the editorial team, there is the issue of who bears responsibility for detecting and notifying victims when two chains of trust — routing and certificates — are broken simultaneously. To what extent should certificate authorities take route integrity into account?

References

• “33-hour BGP hijack of Softaculous traffic prompts security scramble”, by Connor Jones — The Register, 2026-09-01T12:04:00.000Z (ARR)
• Source URL: https://www.theregister.com/security/2026/09/01/33-hour-bgp-hijack-of-softaculous-traffic-prompts-security-scramble/5293608