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 wasn't 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's the part worth sitting with.
What actually happened
AS62390 (NexonHost) began announcing 162.55.80.0/24 — a slice of the Hetzner block hosting 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 Aug 28 to 08:50 UTC on Aug 29, then 20:57 UTC on Aug 29 to 06:10 UTC on Aug 30. 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 attack, not a side effect
Here's the mechanism that makes this worth understanding. A public CA verifies domain ownership with an automated check — typically an HTTP or DNS request to the domain — 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 wasn't 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 didn't 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 checked 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 didn't cryptographically verify the package it downloaded, so a modified package wasn't rejected on that basis. Softaculous's own products weren't affected — only Virtualizor's update mechanism sat in the hijacked address range.
Quick reference
| Fact | Detail |
|---|---|
| Hijacking AS | AS62390 (NexonHost), via transit AS6204 (Zet.net) |
| Affected range |
162.55.80.0/24, part of Hetzner's 162.55.0.0/16
|
| Duration | Two windows, Aug 28–30 2026, ~33 hours elapsed, ~28% average traffic diversion |
| Certificate | Genuinely valid, issued by Let's Encrypt, domain validation routed through the hijack |
| Persistence mechanism | Malicious systemd service, java-jre-update.service
|
| Root cause enabling persistence | Update packages weren't cryptographically signed at the time |
Why certificate checks alone wouldn't have flagged this
A 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 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 isn't a gap specific to any one monitoring vendor — it's 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 wouldn't 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, below what a DNS lookup can see.
One detail worth flagging honestly: a hijack this partial — roughly a quarter of traffic diverted on average, not all of it — is exactly the kind of thing that could plausibly look inconsistent across 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's a plausible mechanism, not a claim that any specific setup would have caught this particular incident — 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 a hijacker's genuinely valid certificate would pass. That's not a criticism unique to this tool. Naming it plainly is more useful than implying a green check means more than it does.
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 is stated as future work — it wasn't implemented at the time of the incident, which was the actual gap that let a routed-around update turn into persistent root access
Covered in more detail on the WebPixie blog, including the full incident timeline and both companies' own accounts.
Top comments (0)