Summary

  • A forged-origin announcement for 162.55.80.0/24 retained Hetzner’s AS24940 at the end of the path, remained RPKI Valid under a permissive ROA, and helped an attacker obtain a valid TLS certificate for Softaculous domains.
  • Virtualizor reconstructed the route through 368 RIPE RIS peers but says attacker-served update responses never reached its logs, so it cannot produce a definitive list of affected installations.
  • The missing evidence object is a privacy-safe update-consumption receipt: a local record binding the requested version, signed manifest, package digest, accepted key, verification decision and installation or rollback result.

There is a temptation, after an infrastructure incident, to treat the largest number in the post-mortem as the size of the impact. In the Softaculous and Virtualizor case, that number is 368. Virtualizor says every one of the 368 peers in its RIPE Routing Information Service sample carried the hijacked route at some point during the incident. It is an arresting statistic. It is not a count of customers, servers, downloads or compromises.

The distinction matters because the incident crossed four evidence systems without leaving the same trace in any two of them. BGP collectors observed paths. A certificate authority recorded a certificate. The attacker’s server answered diverted requests. Virtualizor installations made local decisions about an update package. The first two layers can be inspected from outside. The third was controlled by the attacker. The fourth lived on customer machines. No amount of rhetorical confidence can turn one denominator into another.

LACNIC published a Spanish version of Kentik’s analysis on 10 September. The page is a useful regional news peg, not proof that LACNIC operated the affected infrastructure or endorses every conclusion: it expressly says the authors’ views are their own. Kentik, in turn, draws on the vendor’s incident notice and the route record. Attribution is part of the evidence discipline here. The registry published the case; Kentik analysed the route; Virtualizor described the application impact.

What the route record can establish

At about 20:57 UTC on 28 August 2026, 162.55.80.0/24 appeared in the global table with an AS path ending 6204 62390 24940. The /24 was more specific than Hetzner’s ordinary 162.55.0.0/16. Where both routes were accepted, longest-prefix matching sent traffic for the /24 towards the new announcement.

The path retained AS24940, Hetzner, as the apparent origin. The covering Route Origin Authorisation permitted AS24940 and allowed a prefix as specific as /24. Origin validation therefore had no invalid origin to reject. This was the forged-origin sub-prefix problem described in RFC 9319: a malicious path can append the authorised origin and exploit address space covered by a non-minimal authorisation. RPKI origin validation answered the question it was designed to answer. It did not attest to the truth of every hop in the path.

That is why the phrase “RPKI Valid” must be read as a scoped result, not a safety label. A valid origin says that the final AS and prefix length fit a published authorisation. It does not say that AS62390 was an authorised upstream, that the preceding adjacency was real, that the endpoint belonged to the expected operator, or that a file served over the connection was trustworthy. RFC 9319 recommends minimal ROAs where possible because strict prefix coverage removes this particular unused-subprefix opening. It does not claim minimal ROAs provide full path validation.

Virtualizor places the incident from approximately 20:57 UTC on 28 August to approximately 06:10 UTC on 30 August. Its reconstruction describes two active waves separated by an eleven-hour lull. Across the full window it reports roughly 10,600 route withdrawals, a reminder that a ten-minute sample is not a continuous movie. The vendor also notes that snapshots aligned with the eight-hour routing-table dumps are more reliable and that intervening snapshots can undercount visibility during heavy flapping.

The 368-peer result has another qualification. All 368 peers carried the hijacked route at some point, but not all at the same instant. During an active wave, the reported peak was about 72 per cent of the full peer set. Even that percentage is a topology proxy: it describes the share of observed peers whose best path traversed the hijacker, not traffic volume. A small customer server behind one peer is not equivalent to a hyperscale network behind another. The measurement is highly valuable precisely when its limits remain attached.

What the certificate proves—and does not

The diverted infrastructure also answered certificate-validation traffic. Virtualizor says the attacker obtained a technically valid TLS certificate covering names across the Softaculous product family, including update endpoints. A client following the diverted route could therefore complete an encrypted connection without a certificate warning. Encryption protected the session to the endpoint the routing system delivered; it did not restore the intended endpoint.

Multi-Perspective Issuance Corroboration is designed to make this attack harder. Instead of trusting a single validation path, a certificate authority asks remote perspectives to corroborate domain control. The current CA/Browser Forum requirements, effective 15 June 2026 for the relevant checks, require at least four remote perspectives and corroborating perspectives across at least two RIR service regions. Let’s Encrypt has explained the core threat plainly: an attacker able to hijack or redirect the validation path can fool a single point of observation.

MPIC did not become pointless because a certificate was issued here. Kentik’s argument is narrower. An uncontested more-specific route propagated broadly enough that the remote perspectives could see the attacker’s answer as well. A quorum protects against a local lie by creating disagreement. If the lie becomes the common view, the quorum can agree on the wrong endpoint. Strict ROAs, route monitoring, path-aware controls and diverse certificate perspectives remain complementary; none should be sold as the layer that makes the others unnecessary.

The evidence disappears at the update endpoint

Virtualizor says a malicious update package reached a small number, or handful, of installations. It also says it cannot produce a definitive list. The explanation is operationally credible and institutionally uncomfortable: the malicious responses were served by the attacker and never reached the vendor’s logs.

Ordinary server logs are records of visits to the server that wrote them. During a successful diversion, the absence of a request in the legitimate server’s log is not evidence that no request occurred. It may be evidence that the request went elsewhere. This reverses a familiar incident-response instinct. The system of record becomes least complete at exactly the moment when the attacker succeeds.

The normal update workflow widened that blind spot. Virtualizor’s documentation says the product checks for updates automatically every 24 hours unless auto-updating is disabled; administrators can also trigger updates through the panel or command line. Which installations checked during the roughly 22 active hours? Which of those requests traversed a diverted interval? Which downloads completed? Which package was accepted? Which installation ran? The route record cannot answer those questions, and the legitimate origin’s access log cannot see the attacker’s answers.

The vendor’s disclosure says its update clients did not yet cryptographically verify update packages. It has promised package signing. That is the necessary first repair. A client must reject a package whose signed metadata, digest, version or authorised key does not match. Transport security should never be the only authenticity test for privileged update code.

But signature verification and incident attribution are not the same control. A signature can prevent a future unsigned package from running. It does not, by itself, tell an operator or vendor what happened on every installation during an earlier interval. Even after signing is deployed, investigators need to know whether a client requested version X, received digest Y, accepted key Z, rejected the package, installed it, quarantined it or rolled it back.

The missing object is an installation receipt

The modest remedy is a receipt written where the decision occurs. For each update attempt, the installation should retain a small, tamper-evident record containing the update channel and requested version; request time; signed-manifest digest; package digest; accepted signing key or threshold; verification result; installation, rejection, quarantine or rollback outcome; and any later revocation or repair notice linked to that event.

The receipt need not reveal the customer’s identity to the public. It can remain under the operator’s control, use a pseudonymous fleet identifier and disclose only the minimum proof needed during an incident. A vendor could offer an optional acknowledgement service that accepts a blinded or pseudonymous receipt and returns a timestamped acknowledgement. Large operators could aggregate results internally. Smaller operators could export a single evidence bundle for support. Privacy is a design constraint, not an excuse to omit the record.

This is not telemetry for its own sake. It creates a join between the vendor’s statement—“this manifest and key were authorised”—and the operator’s statement—“this machine requested, verified and acted on this package.” If an attacker controls the route and web endpoint but not the signing key, the receipt records a rejection. If a signing key is later revoked, the operator can identify which machines accepted it. If a malicious package exploits a verifier, the digest identifies the exact population that installed it. If nothing was installed, the same record can narrow unnecessary emergency work.

The receipt also prevents a common post-incident collapse of categories. A RIS peer carrying the route is exposure evidence. An update request during a diverted interval is delivery opportunity. A completed download is acquisition. A successful installation is execution. An indicator of compromise is impact evidence. Those are successive filters, not synonyms. A defensible incident report should publish each count with its own denominator and confidence, then state which joins are unavailable.

The strongest defence of the current response

Virtualizor did several things an accountable vendor should do. It disclosed that a malicious package was delivered, published an indicator of compromise, told operators to rotate and restrict credentials, asked them to preserve evidence, reported the certificate for revocation, reconstructed the routing incident, and promised package signing. Kentik and LACNIC used the episode to explain strict ROAs and monitoring without pretending origin validation provides path truth. Those are substantial actions.

The criticism is not that the incident notice lacks certainty it could reasonably possess. It is that the ecosystem had never required the decision point to leave a portable record. Once the attacker’s server answered the request, the vendor’s central log was outside the transaction. The remaining evidence belonged on the installation. Telling every operator to check is prudent when the population is unknown; it is also the operational cost of not having receipts.

The next version of this post-mortem should therefore be able to place three ledgers beside one another. The route ledger should show which perspectives saw which path and when. The release ledger should show which signed manifest, package and keys were authorised. The installation ledger should show how each local updater acted. None replaces the other. Together they turn a broad warning into a bounded repair list.

Sources