Hetzner IP Space Hijacked to Poison a Virtualizor Update

Check This One File First

If you run Virtualizor, look for this before you read anything else:

ls -l /etc/systemd/system/java-jre-update.service

Virtualizor's advisory is blunt about what its presence means. If the file is there, treat the server as compromised, and contact them rather than deleting it, because the file is evidence.

That is the urgent part and it takes ten seconds. The rest of this is how a file like that reached servers through an update channel that raised no warning at any stage.

What Happened

Between approximately 20:57 UTC on 28 August and 06:10 UTC on 30 August 2026, traffic bound for a block of Hetzner addresses was diverted to a server the attacker controlled. The block, 162.55.80.0/24, carried Softaculous update and billing systems, including the endpoint Virtualizor installations call when they check for updates.

Per the advisory, the announcement came from AS62390, operated by NexonHost, routed through AS6204, operated by Zet.net. Worth stating plainly, because it is easy to read past: naming the networks that carried the route is not the same as naming whoever was behind it. A network can be announcing a prefix because it was compromised itself, or because a customer of theirs did it.

Hetzner normally announces the surrounding 162.55.0.0/16. A more specific route wins over a less specific one wherever it propagates, which is why the /24 took precedence on every network that accepted it.

The window was not continuous. Virtualizor's reconstruction, built from public RIPE routing data rather than provider reports alone, records two waves with a lull of roughly eleven hours between them:

Their measurements are worth quoting accurately, because the headline number and the honest number differ. All 368 of RIPE's collector peers carried the hijacked route at some point. While a wave was active, the share whose best path went through the attacker peaked at about 72 percent of that full peer set. Across the whole 33 hours, the time-weighted average was 28 percent. Both figures are a routing-topology measure, not a count of bytes.

Why Nothing Warned Anybody

Every automated safeguard in this chain did exactly what it was built to do.

The certificate was genuine. Certificate authorities prove you own a domain by connecting to it. That check travelled over the same hijacked route, reached the attacker's server, and came back satisfied. Let's Encrypt issued a valid certificate covering the Virtualizor domains, so affected connections showed no warning, because there was nothing to warn about. Softaculous have since reported it for revocation.

The route passed validation too, and this is the part neither advisory examines. There is a system called RPKI in which the owner of an address block publishes a signed record naming which network may announce it, and how finely the block may be subdivided. Networks that check these records reject announcements that fail.

Two things had to be true for the hijack to satisfy that check, and both were.

The first is the origin. Virtualizor state that the attacker "kept the real origin on the path tail and never appeared as origin itself", and we confirmed it independently: querying RIPE's routing history for the prefix across the incident returns exactly one origin network, Hetzner's own AS24940.

The second is the prefix size. According to RIPEstat's historical record, and this is a single source rather than two, Hetzner's signed record for 162.55.0.0/16 permitted subdivision down to /24, and had done since March 2021.

Allowed prefix size, matching origin network. The hijacked route did not slip past origin validation. It satisfied it.

The update package was not signed. Virtualizor update clients did not cryptographically verify update packages. The one check that could have caught this was the one that did not exist.

What Changed Since

Hetzner's signed record no longer permits subdivision. It now caps the block at /16, which we confirmed on 2 September against two independent sources. Any announcement of a /24 inside that range is now invalid whichever network claims it, and validating networks will drop it. That closes this particular door.

The change does not appear in the historical series through 1 September, so it looks to have been made after the incident ended and after the advisories went out.

There is a trade in it worth noticing. Hetzner's own mitigation during the incident was to announce the affected /24 themselves, which beat the hijacker at his own game. Under the tightened record that announcement would now be invalid too, so the same response is no longer available. Tighter records make hijacks like this fail, and they also remove a defender's ability to fight a more specific route with a more specific route.

On Hetzner's Part in It

Here we stay close to what is documented, because two of the three parties have said nothing publicly.

Softaculous write that they reported the hijack to Hetzner and escalated repeatedly, and that Hetzner began announcing the /24 directly at about 08:50 UTC on 29 August, roughly twelve hours after the hijack began, at which point diversion dropped to zero within minutes. They also state that Hetzner did not proactively notify them, and that they contacted Hetzner again on 31 August, after which Hetzner acknowledged the incident.

That is one party's account of the other. Hetzner have published nothing about the incident on their status page or in their pressroom, and are not quoted anywhere in the coverage. Their acknowledgement, per Softaculous, was private.

Softaculous say they have no evidence of compromise involving Softaculous itself or their other products, and that the investigation continues. They have released Virtualizor 3.2.9.9 carrying, in their words, "a mitigation tool for known exploits".

What To Do

Softaculous cannot produce a definitive list of affected servers, so the checking falls to operators.

Look for the service file, and if it is there, contact them rather than deleting it.

Regenerate your API keys from the Softaculous client area and update them on your servers.

Audit for persistence. Unfamiliar SSH keys, accounts nobody created, scheduled tasks nobody remembers adding.

Reset client area passwords if anyone logged in during either wave, since those addresses served the client area and billing site as well as updates.

The Part That Generalises

Nothing here required breaking encryption, stealing a signing key, or getting inside a vendor's build system. It required convincing the internet's routing table of something false for a day and a half, and letting every automated check downstream honestly confirm what it was shown.

It is the same shape as the npm worm of 4 August, which we covered in eleven compromised packages and a 53 minute attack. There the malicious release even carried a valid provenance attestation, because it was built by the real repository's own pipeline.

If your software updates itself over the network, the question is not whether the connection is encrypted. It is whether what arrives is signed by someone you decided to trust, and whether the client verifies that signature before installing it.

If you run hosting infrastructure and want the update paths, key rotation and routing exposure across your fleet looked at properly, we do security and compliance work on exactly this, and an incident like this is a reasonable place to start that conversation.

Sources: Virtualizor security advisory, BGP hijacking, Softaculous incident update, 31 August 2026, RIPEstat routing data for 162.55.80.0/24, RIPEstat ROA history for 162.55.0.0/16