Hypervisor-Tier Access Arrived Dressed as a Software Update
Rented VPS panels sit two vendor hops below your risk register, and the only available evidence about the 33-hour window is a written answer from a company that kept no logs.
The blast radius sits below the vendor map
Virtualizor is the panel hosting companies use to provision rented VPS fleets. A poisoned update hands hypervisor-tier access to every virtual machine under that panel, including workloads owned by other tenants on the same host. Marketing sites, staging and acquired-subsidiary infrastructure on rented VPS are fourth-party exposure, rarely on any third-party risk register. The contract is with the hosting provider. The provider's is with Softaculous.
Why every control returned "valid"
Route Origin Validation answers one question: is the origin AS authorized to announce this prefix. The path behind it goes unchecked. The announcement appended Hetzner's AS24940 as apparent origin behind AS62390 and transit AS6204, so the check passed as designed. The /24 was carved from Hetzner's normal /16, so best-path selection preferred it everywhere it was accepted. The certificate side is the same shape: a domain-validated certificate needs only control of traffic to the domain, which the hijack supplied for 33 hours. Where an update channel relies on TLS for authenticity, control of routing is control of authenticity.
The check passed because the attacker left the legitimate origin in the path. ROV only reads the origin.
The evidence problem is the real finding
Virtualizor cannot say how many customers were affected. None of the hijacked traffic crossed its own infrastructure, so there is no vendor-side telemetry to query. It warns that anyone who paid on the site during the window most likely had financial data stolen, while conceding it is unclear whether the operator collected payment data at all. Network analyst Doug Madory confirmed the forged origin publicly on 1 September. That is how the technique became knowable.
For any provider in the estate, "we were not affected" is an assertion, not a finding. The evidence available is an answer to one question: were Virtualizor updates applied between 28 and 30 August. Panels that cannot answer are being treated as compromised, with panel credentials, API keys and anything stored in the panel rotated, and provisioning logs and fleet outbound connections reviewed.
The detection that would have collapsed 33 hours into minutes
Certificate Transparency monitoring on owned domains is the fastest detection here: an unrequested certificate, logged publicly, minutes after issuance. CAA records with account-URI pinning, where the CA supports it, narrow who can issue at all. Both are days of work on infrastructure already owned. Routing monitoring is the slower half: alerts on hijacks of owned and top-vendor prefixes, confirmation that transit providers enforce IRR and peer-lock filtering, and a routing risk register entry noting that RPKI origin validation does not defend against forged-origin path hijacks. Path validation and ASPA fix this on a multi-year deployment timeline.
The pattern this belongs to
Two other items in today's reporting share the property. An endpoint agent misreported its own protection state at fleet scale. Browser extensions that passed vetting at install turned hostile through a routine store update. Different layers, one failure: the check ran and answered affirmatively when it should not have. Controls whose output is a verdict rather than an observation are worth re-testing this quarter.
What to do
Demand written confirmation from every hosting provider, reseller and VPS vendor in the estate on whether Virtualizor updates were applied between 28 and 30 August, and rotate panel credentials, API keys and panel-stored secrets for any that cannot answer by Friday.
Stand up Certificate Transparency monitoring for all owned domains and set CAA records with account-URI pinning this week.
Add BGP hijack monitoring for your own prefixes and your top 10 critical vendors' prefixes this quarter, and record in the routing risk register that RPKI origin validation does not stop forged-origin path attacks.