On 28 August 2026, a new route to 162.55.80.0/24 appeared on the Internet. The address range contained infrastructure used by Softaculous, including endpoints for its Virtualizor server-management software. The route was unauthorized, but networks that accepted it sent traffic for those addresses toward an attacker-controlled server. Some Virtualizor installations subsequently received a malicious update.
The incident illustrates a difficult operational truth: a route can pass RPKI origin validation because of a permissive ROA maxLength, and still take traffic somewhere it should not go. It also shows why routing security and software-update integrity have to work together.
How the traffic was diverted
The legitimate route covering the affected addresses was Hetzner Online’s 162.55.0.0/16, originated by AS24940. At approximately 20:57 UTC on 28 August, an unauthorized announcement for 162.55.80.0/24 appeared through AS62390 (NexonHost) and transit AS6204 (Zet.net). A /24 is more specific than a /16, so routers that learned both routes forwarded traffic for the /24 according to the new announcement. The diversion occurred in two waves, ending on 30 August at approximately 06:10 UTC; it was not continuous throughout that entire window. The route also flapped heavily within the waves. Softaculous’s update and Virtualizor’s incident report provide the timeline. The public path does not establish how the unauthorized route entered AS62390, and we should not infer that from its position in the path.
The advertised AS path ended with AS24940, the legitimate origin, even though the route had passed through AS62390. At the time, the ROA for the covering /16 had a maxLength of /24, authorizing AS24940 to originate prefixes as specific as /24. Route Origin Validation (ROV) therefore classified this unauthorized /24 as Valid. ROV checks whether the advertised origin and prefix length match a ROA; it does not prove that the rest of the AS path is genuine or that the announcement was authorized by the origin network. APNIC’s incident analysis explains this failure mode, which is also within the stated limits of RFC 6811.
The attacker also obtained a technically valid TLS certificate for affected domains after certificate-validation traffic followed the hijacked route. Let’s Encrypt uses multi-perspective issuance corroboration (MPIC): it checks domain control from multiple network locations so a localized routing hijack should produce conflicting answers. This /24 had no legitimate /24 competing with it and propagated widely enough for the attacker’s endpoint to satisfy those checks. Virtualizor reports that all 368 peers in its RIPE RIS sample carried the hijacked route at some point; during active-wave measurements it reports a median of 266 diverted peers, about 72% of that sample.
HTTPS clients connecting to the diverted service therefore had no certificate warning. According to Virtualizor, its update clients did not cryptographically verify downloaded update packages at the time, and a malicious package reached a small number of installations. A valid TLS connection was insufficient to establish that the software itself came from the vendor.
What is ROA maxLength?
A ROA’s maxLength sets the longest prefix length an AS is authorized to announce. A ROA for 162.55.0.0/16 with maxLength 16 authorizes only the /16. With maxLength 24, it also validates any /24 inside it, which is why the forged 162.55.80.0/24 was classified as Valid.
How could the attack have been prevented?
No single control would have eliminated every possibility of traffic diversion. Different measures act at different points in the chain.
1. Set ROA maxLength to match the prefixes you announce
If an operator normally announces a /16, a ROA for that /16 should generally authorize /16, not every more-specific prefix down to /24. With an exact-length ROA, the forged 162.55.80.0/24 would have been RPKI Invalid despite carrying AS24940 at the end of its path. Networks rejecting invalid routes would then have dropped it.
Operators that legitimately use more specific routes, including for traffic engineering, DDoS response, or emergency counter-announcements, need explicit ROAs for those announcements and a process to update them before changing BGP policy. In this case, if the /16 had been authorized only at its exact length, Hetzner’s defensive /24 would also have been Invalid at ROV-enforcing networks until it had a matching ROA. The incident playbook should therefore cover who can authorize and publish an emergency ROA, how to verify that validators have received it, and when to announce and withdraw the defensive route. This is a matter of planning, not a blanket rule against deaggregation. RFC 9319 discusses minimal ROAs and operational considerations for more-specific DDoS mitigation routes.
Tighter ROAs would have reduced propagation where ROV was enforced. They could not guarantee that every network on the Internet would reject the route. Limiting propagation would also have increased the chance that Let’s Encrypt’s separate validation perspectives disagreed and refused the attacker a certificate. This is a likely benefit, not a guarantee. APNIC reports that Hetzner subsequently tightened the affected /16 ROA to /16, but its analysis found roughly 50 other Hetzner ROAs still allowing more specifics than were then being announced. That count is a snapshot from the published analysis, not a claim about the current inventory.
2. Filter announcements at the customer edge
A transit provider should check what each customer is authorized to announce and apply route filters accordingly, using maintained prefix and origin information. An unexpected /24 with a plausible-looking AS path should not be accepted simply because its origin validates under RPKI. Maximum-prefix limits can also contain some mistakes, although they do not establish who owns a particular prefix.
The public routing record shows the path through AS62390 and AS6204; it does not by itself establish exactly how the unauthorized announcement entered AS62390 or which operational check failed. The practical lesson for an upstream is to validate customer announcements at ingress, including delegated or downstream prefixes, and keep those authorizations current. First-AS enforcement alone would not solve this example: the immediate neighbor could present its own ASN first while retaining the forged legitimate origin at the end of the path.
3. Validate the path, not just the origin
ROV only checks the last AS in the path. ASPA (Autonomous System Provider Authorization) adds a check on the hops before it. An ASPA record, published in RPKI, lists the networks an AS uses as upstream providers. A validating router can then test each adjacent pair of ASes in a received path and ask whether the AS that passed the route on was authorized to receive it from the AS below it.
After the incident, Hetzner published an ASPA record for AS24940 listing its authorized providers, and AS62390 is not on it. How much that would have caught depends on where the validating network sits. A network that learns a route from a customer or a peer treats a single unauthorized hop as enough to make the whole path Invalid. AS6204, receiving the /24 from its customer AS62390, is exactly that case. Had it validated ASPA under that record and dropped Invalid routes, the announcement would have stopped at its first transit hop.
Networks that learn a route from one of their own providers apply a looser test, because legitimate routes travel up, sometimes across one peering link, and back down. Unless AS62390 or AS6204 also published ASPA records, those networks could not rule out a path in which AS24940 peers with AS62390 and AS62390 passes the route down to AS6204. The result there would be Unknown, not Invalid. ASPA coverage therefore depends on how much of the path is attested, not only on the victim’s own record. An attacker aware of the victim’s record could also insert one of its listed providers into the forged path, and catching that would depend on that provider publishing its own ASPA.
The record was not present during the attack, and publishing one does not filter routes at networks that have not deployed validation. The verification procedure is still an IETF Internet-Draft (draft-ietf-sidrops-aspa-verification, revision 28 as of August 2026), so operators should check what their own validators and routers support before relying on it. Publishing an accurate ASPA for your own AS costs little and starts protecting you at every network that does validate. APNIC’s follow-up provides more context.
4. Watch your prefixes from outside your own network
An origin-only alert could have missed this incident: the /24 appeared to originate from the expected AS. A more useful alert would have combined three observations: a previously unseen more-specific prefix, an unexpected AS immediately upstream of the apparent origin, and sightings across independent BGP collectors, even if the route appears and disappears repeatedly. Virtualizor reports approximately 10,600 withdrawals during the incident. An alert requiring the route to remain continuously visible could miss such a pattern. These observations are reasons to investigate, not automatic proof of an attack; legitimate traffic engineering can also change prefix length and paths.
The response should have an owner and a tested escalation path. Hetzner began announcing the same /24 at about 08:50 UTC on 29 August, and diversion fell to near zero. Its defensive /24 was then withdrawn around 14:10 UTC; the unauthorized /24 reappeared around 20:00 UTC, opening the second wave. The public sequence does not establish why the defensive route was withdrawn or whether leaving it up would have ended the incident by itself. It does show the need to keep a counter-announcement in place, where operationally feasible, until the unauthorized route is contained and the root cause addressed. Verify the result at multiple external vantage points, then keep watching after an apparent recovery.
5. Limit and monitor certificate issuance
CAA records can restrict which certificate authorities may issue for a domain. But a basic CAA record allowing Let’s Encrypt would not have stopped this case: the attacker obtained a Let’s Encrypt certificate. Where operationally appropriate, CAA account binding and validation-method restrictions can narrow issuance further; a method that depends on control of DNS rather than the hijacked web endpoint changes this particular attack path. Review DNS and account security before relying on that design.
Monitor Certificate Transparency logs for unexpected certificates covering production and update domains, and have a revocation and incident-response procedure. CT monitoring helps detect issuance; it does not block a certificate before it is issued or stop a client from accepting it.
6. Verify the update package independently of the network path
The most direct way to break the final step is for the client to verify a vendor signature on the package before installation, using a trusted key that the update server cannot silently replace. The signed metadata should bind the package to its version and checksum, with appropriate protection against stale or replayed updates. Then a hijacked endpoint and even a valid TLS certificate would not, by themselves, make an attacker-supplied package installable.
On 21 September, Softaculous announced Softaculous v6.4.1, with RSA/SHA-256 signature verification for update packages and signed API responses. Its release note does not specify key-handling or replay protections, so those remain recommendations here, not claims about the release. Nor does the Softaculous release establish that Virtualizor update clients enforce the same verification: the Virtualizor advisory describes package signing as work to put in place.
What can a NOC actually see?
External BGP feeds and, where available, BMP from routers can show new announcements, AS-path changes, and the effect of a corrective route. RPKI data can show whether the route is Valid, Invalid, or NotFound. Neither a Valid label nor a normal HTTPS certificate is a clean bill of health for the full path or the downloaded code.
A tool such as Noction Flow Analyzer can help answer a different set of questions from exported traffic data: which destinations were contacted, when update traffic changed, and which networks or hosts warrant further investigation. NetFlow or IPFIX records do not, on their own, authenticate a BGP AS path or prove that an update was malicious. Correlating flow records with routing events, DNS changes, certificate records, and host evidence gives the incident team a stronger timeline than any single source can provide.
The operational takeaway
This attack crossed three trust boundaries: routing delivered clients to the wrong endpoint; the broad diversion defeated multi-perspective certificate validation and TLS did not reveal the diversion; and the update client accepted code without an independent package check. Tight ROA maxLength values and ROV would have made the route harder to propagate. Customer-edge filtering could have stopped it earlier. External monitoring, a sustained counter-announcement, and certificate alerts could have shortened or contained the incident. Verified software signatures could have prevented a diverted update request from becoming a malicious installation.
For an ISP or hosting NOC, the actionable question is not simply, “Are our prefixes covered by RPKI?” It is: Which more-specifics have we authorized, which neighbors can announce them, how quickly would we notice a path that looks wrong, and what happens if traffic is diverted anyway?
