A 33-Hour BGP Hijack Worked Because the Updates Were Not Signed

2 SEP 2026 — Softaculous says an attacker hijacked BGP routing for its Hetzner-hosted addresses between 28 and 30 August, redirecting its update and billing systems and delivering a malicious Virtualizor update. The hijack lasted about 33 hours. It worked because the packages were not cryptographically signed, so transport was the only thing establishing trust.

What happened

The attack window ran from 20:57 UTC on 28 August to 06:10 UTC on 30 August. The attacker falsely announced routes for IP addresses belonging to Softaculous, pulling traffic bound for its update systems and its client and billing portal.

A malicious Virtualizor update reached what the vendor describes as a small number of installations, a handful of servers rather than the general user base. No other Softaculous products were affected.

The payload created a systemd service file at /etc/systemd/system/java-jre-update.service. Softaculous advises administrators to check for that artefact and to audit for unauthorised SSH keys, accounts and scheduled tasks. Version 3.2.9.9, released on 1 September, adds a Security Analyzer tool, and the vendor says future versions will cryptographically sign all packages.

The routing was the vector and the signing was the failure

BGP hijacking is the obvious headline and it is the less interesting half. Announcing someone else's prefixes and having the internet believe you is a known weakness of a protocol built on trust between operators, and it happens regularly, usually by accident.

What determines whether a hijack matters is what the traffic was protecting. If the package were signed, a hijack would only let the attacker serve bytes the client would then refuse. The signature would not verify against a key the attacker does not hold.

Here there was no signature to fail. The update client had one way of knowing it was talking to the vendor, which was the route, and the route is exactly what was taken. Adding signing, which the vendor is now doing, makes the same hijack an availability problem rather than a compromise.

Thirty-three hours is a long time to hold a prefix

Route hijacks are visible. Every announcement propagates through the global routing table, public monitoring systems record them continuously, and services exist that alert an operator when someone else announces their space.

A hijack that persists for a day and a third points to a monitoring failure rather than a sophisticated attack. Either nobody was watching those prefixes, or the alerting went somewhere nobody reads.

The defence is RPKI, which lets an address holder publish a signed statement about which networks may announce their prefixes, so that other operators can reject announcements that contradict it. Adoption has grown substantially and is still not universal, and it protects only the networks that both publish and validate.

The billing portal was redirected too

The notice mentions the client and billing portal alongside the update systems, and that half has had almost no attention.

Traffic to a billing portal for 33 hours means credentials submitted during that period went to whoever controlled the route. TLS is the defence, and it holds only if the attacker could not obtain a certificate for the hostname — which is exactly what a routing hijack makes possible, because domain validation for a certificate is itself a network reachability test that the hijacker now passes.

Nothing in the reporting says a certificate was issued or that any credential was captured, and no such claim is made here. It does mean that anyone who signed into that portal during the window should change the password and check for sessions and API tokens they do not recognise, on the ordinary principle that you assume the worst about a window you cannot see into.

What was compromised is worse than the count suggests

A handful of servers sounds like a contained incident, and Virtualizor is a control panel for VPS hosting. The machines running it are hypervisors, and each one hosts customer virtual machines.

Root on a hypervisor means access to every guest on it, without touching any guest's own defences. Guest disk images can be read from the host, memory can be inspected, and none of that appears in a customer's logs, because from inside the virtual machine nothing happened.

Counting Virtualizor installations that took the update therefore understates the affected population by however many virtual machines each host was running. Those customers have not been told, because the notice went to their provider.

What to do this week

For anyone running Virtualizor: update to 3.2.9.9, then check for the named systemd unit and audit authorized_keys, accounts and scheduled tasks on the host — not because the artefact list is exhaustive but because it is the part that is known. A hypervisor that took the update during the window is a rebuild candidate rather than a cleanup one, and telling your customers is part of the work.

The question for everyone else is which of your own software supply chains verify what they download. A surprising number of internal tools, agent installers and vendor update mechanisms still trust the connection rather than the payload. The test is simple: would the client install a package you served from a server you control?

We reported that Broadcom is selling verified builds of open-source libraries, and noted that a reproducible signed build proves the binary matches the source rather than that the source is safe. This incident is the case where signing would have been decisive, because the source was fine and the delivery was not.