BGP Hijack Used to Spread Malware: How a Routing Mistake Infected Networks

In early September 2026, attackers abused a routing weakness at hosting provider Hetzner Online to hijack a block of IP addresses belonging to Softaculous. By announcing a more‑specific route, they diverted traffic meant for software‑update servers and pushed malware‑laden updates to unsuspecting users. The incident shows how a single misconfiguration in routing security can undermine even widely adopted protections such as RPKI.

Overview of the BGP Hijack Incident

On Friday, September 2, 2026, a small prefix—162.55.80.0/24—appeared in the global routing table with an AS path that made it look legitimate to many networks. The space normally belongs to Softaculous, a UAE‑based maker of the Virtualizor management platform and the Softaculous auto‑installer. By announcing this more‑specific route, attackers diverted traffic intended for Softaculous’ update and billing servers to systems under their control.

The hijack persisted on and off for about 22 hours, during which time users pulling updates could have received malware‑laden packages. Because Softaculous clients did not cryptographically verify update packages at the time, the malicious payload was not rejected.

The attack combined a BGP hijack with weaknesses in TLS certificate , allowing the attackers to obtain certificates for the hijacked addresses and further mask the malicious traffic.

How BGP and RPKI Work

Border Gateway Protocol (BGP) is the routing system that lets autonomous systems (ASes) announce which IP prefixes they originate. In the early Internet, these announcements were trusted implicitly. Over time, attackers abused this trust by announcing IP ranges they did not control.

To counter such hijacks, the industry adopted Resource Public Key Infrastructure (RPKI) with Route Origin (ROV). RPKI uses cryptographically signed Route Origin Authorizations (ROAs) that state which AS is allowed to announce a given prefix and what prefix length is valid. Routers that enable RPKI ROV will reject announcements that do not match the ROA.

In a properly configured network, a more‑specific announcement (e.g., a /24 inside a /16) is only accepted if the ROA explicitly permits that length.

Hetzner Online had configured its RPKI validator to accept sub‑prefixes as small as /24, even though the legitimate ROA for the 162.55.0.0/16 block only authorized origins at the /16 level. By allowing the more‑specific /24 to be considered valid, the hijacked route appeared RPKI‑compliant and was preferred by routers due to longest‑prefix‑match rules.

Moreover, the attackers exploited the fact that the hijacked /24 was used for TLS endpoints. By controlling that address space, they could present themselves as legitimate to certificate authorities, obtaining TLS certificates that further masked the malicious traffic.

Why This Matters

The incident demonstrates that routing security is not just a concern for large transit providers; any organization that announces IP space or relies on update mechanisms can be affected. A breakdown in RPKI configuration, missing monitoring, and lack of code signing together created a path for malware to reach thousands of systems.

For network operators, the event underscores the need to enforce strict ROA‑based filtering and to monitor BGP feeds in near real‑time. For software vendors, it highlights the necessity of cryptographically signing update packages and verifying those signatures on the client side.

When these controls are in place, the attack surface for BGP‑based supply‑chain intrusions shrinks dramatically, protecting both infrastructure and end‑users.

Technical Breakdown: How the Attack Bypassed Defenses

Several errors aligned to enable the hijack:

• Lax RPKI settings at Hetzner. The operator allowed /24 announcements to pass , despite the ROA only covering the broader /16.
• Forged AS path. The attackers appended AS24940 (Hetzner) as the rightmost AS in the path, making the route appear to originate from the legitimate holder.
• Missing monitoring. Both Hetzner and its downstream peers (Zet.net and Nexon Host) failed to detect the anomalous announcements for many hours.
• No code signing for updates. Softaculous update clients did not verify cryptographic signatures, so malicious payloads were accepted.
• TLS abuse. By hijacking the /24 used for domain , the attackers could satisfy Let’s Encrypt’s multi‑perspective checks and obtain trusted certificates.

As BGP expert Ben Cartwright‑Cox observed, the lapse was “silly, preventable mistakes” that together created a perfect storm.

The source provides a detailed timeline of the two hijack pulses and the delayed response times, showing how the hijack was active, then briefly reclaimed, then reactivated.

Lessons from the Comedy of Errors

The incident offers concrete takeaways for network operators and software vendors:

• Enforce strict RPKI : reject any announcement more specific than the authorized prefix length unless explicitly covered by an ROA.
• Deploy real‑time BGP monitoring and alerting to catch unauthorized announcements within minutes, not hours.
• Apply cryptographic signing to all software update mechanisms and require clients to verify signatures before installation.
• Restrict TLS endpoints to tightly controlled address ranges and consider using CAA records to limit which CAs can issue certificates for your domains.
• Conduct regular reviews of routing policies and third‑party transit relationships to ensure no overly permissive configurations exist.

When these controls are in place, the attack surface for BGP‑based supply‑chain intrusions shrinks dramatically.

If you operate a network that announces IP space, verify your RPKI configuration today. Use tools such as rpki-client or the RIPE NCC RPKI validator to confirm that only authorized prefix lengths are accepted.

If you manage software that distributes updates, implement code signing (e.g., using PGP or Sigstore) and enforce verification on the client side. Additionally, lock down the IP addresses used for TLS and monitor them for unexpected announcements.

Stay informed about emerging routing threats by following reputable security feeds and participating in industry groups like MANRS (Mutually Agreed Norms for Routing Security).

What to Do Next

In a well-coordinated operation, the unknown attackers exploited weaknesses in the routing security setup of hosting provider Hetzner Online and the process for attaining valid TLS certificates. That is the specific detail to check before acting on biz & it, border gateway protocol, and supply chain attack.

FAQ

What is a BGP hijack?

A BGP hijack occurs when an attacker falsely announces ownership of an IP prefix, causing traffic to be redirected through networks they control.

How did the attackers bypass RPKI in this case?

Hetzner’s RPKI validator was configured to accept /24 announcements, even though the legitimate ROA only covered the broader /16, allowing the more‑specific hijacked route to appear valid.

Why were Softaculous update clients vulnerable?

At the time of the attack, Softaculous did not require cryptographic verification of update packages, so malicious payloads were not rejected.

Can TLS certificate abuse happen with other methods?

Yes. If attackers control the IP addresses used for domain , they can trick CAs into issuing certificates; using CAA record locking and restricting IPs reduces this risk.

What steps can small hosting providers take to improve routing security?

Implement strict RPKI filtering, monitor BGP feeds with alerts, enable BGP session authentication (TCP-MDS or TTL security), and join initiatives like MANRS.

External Sources and Further Reading

• Ars Technica – BGP hijack infecting networks caused by a comedy of errors