A valid TLS certificate didn't save Virtualizor from a BGP hijack

On 28 August 2026, a network operator hijacked a block of Hetzner's IP space and used it to serve a malicious update to Virtualizor installations. The certificate the attacker's server presented was not forged, spoofed, or self-signed. It was a real certificate, issued by Let's Encrypt, that passed every check a browser or a monitoring tool runs. That is the part worth sitting with.

What actually happened

AS62390 (NexonHost) began announcing 162.55.80.0/24, a slice of the Hetzner block that hosted several Softaculous systems, through transit provider AS6204 (Zet.net). The announcement kept AS24940 (Hetzner) on the AS path, so it looked like a legitimate, more specific route rather than an obvious forgery. Under standard BGP route selection, the more specific announcement wins, so networks that accepted it started sending traffic for those addresses to the hijacker instead of Hetzner. Both companies published detailed incident posts, Virtualizor's own account and Softaculous's own account, confirming the same facts independently.

The hijack ran in two separate windows, not one continuous outage: 20:57 UTC on 28 August to 08:50 UTC on 29 August, then 20:57 UTC on 29 August to 06:10 UTC on 30 August. It was also never universal. Around 72% of RIPE RIS collector peers carried the hijacked route while it was active, and the time-weighted average diversion across the full window was roughly 28%. Most networks, most of the time, were still reaching the real Hetzner infrastructure.

The certificate was the actual attack, not a side effect

Here is the mechanism that makes this worth writing about. A public certificate authority verifies domain ownership by making an automated check, typically an HTTP or DNS request to the domain in question, before issuing a certificate. Let's Encrypt's validation traffic for the affected domains was itself routed through the same hijacked path. The attacker's server answered that validation check the same way the real server would have, and Let's Encrypt issued a certificate covering 28 real domain names, including virtualizor.com, api.virtualizor.com, and files.virtualizor.com.

That certificate was not weaker or different from a legitimate one. Chain validation, hostname matching, cryptographic signature checks, all of it would pass, because the certificate genuinely was issued for the right name by a real CA following its normal process. The hijack did not bypass certificate validation. It compromised the input the validation process trusts.

What actually got delivered

A malicious Virtualizor update package reached a small number of servers, specifically the ones that happened to check for updates during an active diversion window. Virtualizor's own post names the indicator of compromise: a systemd unit at /etc/systemd/system/java-jre-update.service, installed to maintain root access. The update client did not cryptographically verify the package it downloaded, so a modified package was not rejected on that basis. Softaculous's own products were not affected, only Virtualizor's update mechanism was in the hijacked address range.

Quick reference

Why certificate checks alone would not have flagged this

A monitoring tool that validates a certificate's chain, expiry, and hostname is checking a real, valid property of a real certificate. It has no way to know that the network path a specific request took to reach that certificate was hijacked, because from the connecting client's point of view, the TLS handshake looks completely normal. This is not a gap specific to any one monitoring vendor. It is a structural limit of certificate-validity checking as a category: the check confirms the certificate is legitimate, not that the server presenting it is the one you meant to reach.

DNS-based checks would not have caught it either. The DNS records for the affected domains never changed during this incident, per both companies' accounts, the attack operated entirely at the network-routing layer, a layer below what a DNS record lookup can see.

One detail is worth flagging honestly rather than glossing over: a hijack this partial, roughly a quarter of traffic diverted on average rather than all of it, is exactly the kind of thing that could plausibly look inconsistent from different monitoring vantage points, if a check running from multiple locations happened to sample both a diverted and a non-diverted path close together. That is a plausible mechanism, not a claim that any specific monitoring setup would have caught this particular incident, since it depends entirely on which networks a given check happens to route through at the moment it runs.

WebPixie's SSL monitoring validates exactly the properties described above, chain, expiry, hostname, signature, the same properties that a hijacker's genuinely valid certificate would pass. That is not a criticism unique to this tool. Naming it plainly is more useful than implying a green check means more than it does.

The mechanisms that could have flagged this sit outside certificate-validity checking entirely. RPKI-based route-origin validation lets a network reject a more-specific route announcement that doesn't match the origin AS a prefix's owner registered, which would have blocked the hijacked announcement outright rather than merely detecting its effects. Certificate Transparency log monitoring catches the other half after the fact, an unexpected certificate issued for your domain shows up in the public log the moment a CA issues it, regardless of which network path the validation check happened to take. Neither replaces certificate-validity checking; they cover the layer below it that this incident actually broke.

What actually changed

• Virtualizor shipped 3.2.9.9: with exploit mitigation for the specific update-check behavior the hijack abused
• The compromised certificate was revoked: reported to Let's Encrypt after the incident
• Cryptographic package signing: stated as future work, not yet implemented at the time of the incident, which was the actual gap that let a routed-around update turn into persistent root access