Longest prefix match happens before anything you would call security. A router holding both 162.55.0.0/16 and 162.55.80.0/24 forwards those 256 addresses to the /24, and the /16 is never consulted for them [3][1]. AS path length does not break that tie. Neither does RPKI, because origin validation decides whether a route enters the table, not which route already in the table wins [4].
So the question is why the /24 entered the table at all. Virtualizor's writeup says the announcement kept AS24940, Hetzner, on the path as the apparent origin [4], and Doug Madory's read is that the forged origin made the route RPKI-valid, with a hijack path of 6204 62390 24940 against a legitimate path of just 24940 [5]. Origin validation compares three things against a ROA: the prefix, its length, and the origin ASN [3]. Forging the ASN handles one of them. The length is handled by whoever set maxLength on the ROA covering that space, because a /24 announced with origin 24940 comes out Valid only if that ROA permits prefixes as long as /24 [3]. maxLength is the field operators widen so they never have to reissue a ROA after deaggregating. That is the cost of leaving it wide.
Then the window. 20:57 UTC on 28 August 2026, running just under 33 hours, closes at roughly 05:57 UTC on 30 August [1][6][2]. Inside it, the attacker obtained a TLS certificate in Softaculous's name and stood up a clone site that served malicious Virtualizor updates [7].
The certificate deserves a closer look. Virtualizor's account says only that one was obtained [7]. That does not require a compromised CA. Reachability-based domain validation asks whoever answers at the address the name resolves to, and the attacker held the route to those addresses, which host a number of Softaculous systems, for a day and a half [1][2][5]. Controlling the route was enough to control the name, and controlling the name was enough to get a certificate issued.
The measurable part of this incident ends with the traffic itself. Virtualizor says it cannot tell how many users were affected because it never saw or logged the hijacked traffic, which passed exclusively through the attacker's infrastructure [8]. Virtualizor has not published a victim list. For your own exposure to be zero, one of two things has to hold: your updater made no fetch in that window, or the /24 never entered your transit provider's table. The first is in your egress logs. The second you mostly cannot reconstruct after the fact.
The reach is the reason to care about a hosting panel at all. Virtualizor is what hosting companies use to manage the VPS fleets they rent to customers [10], so a malicious update lands on the control plane for other people's servers. Virtualizor also warns that users who made payments on the site during the attack most likely had financial data stolen, while saying it is unclear the attackers were even after it [9]. The company has not attributed the incident [11].
The condition for this to transfer to your own updater is narrow and checkable. It transfers wherever the client verifies nothing about the payload that the transport has not already asserted. Where that holds, 33 hours of someone else's routing is 33 hours of your code execution [6][7].
