A BGP hijack pushed a malicious Virtualizor update onto production hypervisors

August 28, 2026, 20:57 UTC. August 29, 10:33 UTC. August 30, 06:10 UTC. Over 33 hours, attackers hijacked a block of 256 IP addresses belonging to Softaculous, the UAE-based maker of Virtualizor, and used it to push a trojaned software update to production hypervisors. Five servers out of 34. That is how many machines one infrastructure provider confirmed were root-compromised. Why it matters: the hijacked route was RPKI-valid, and the update package was unsigned. The BGP hijack did not need to defeat either one.

What actually happened

The vector is a textbook supply-chain attack with a non-textbook entry point. Instead of compromising Softaculous’s build servers, the attackers hijacked the routing that leads to its update servers. The prefix 162.55.80.0/24, a more specific slice of 162.55.0.0/16 normally originated by Hetzner (AS24940), was announced along the path AS6204 (Zet.net), AS62390 (Nexon Host), then AS24940. During the incident window, a Virtualizor installation whose traffic was diverted could receive a malicious update package from the attacker’s server.

The instructive detail is that the route passed RPKI validation. According to Doug Madory, head of internet analysis at Infoblox and author of a retrospective published at Kentik, the attacker appended 24940 as the rightmost ASN in the path, which made the announcement conform to the ROA: it required origin AS24940 and allowed a prefix length anywhere between /16 and /24. An RPKI-valid route is not a legitimate route — it is only a route that ticks one box.

Two failures that stack

The attack rests on the stacking of two independent failures, neither of them sophisticated.

The first is lax routing configuration at Hetzner. The hoster let the attackers intermittently divert traffic over two spans in a 33-hour window. It reclaimed the space 12 hours after the hijack began by announcing the correct path, then stopped announcing that path — which let the attacker run the same hijack a second time. This time it took almost 10 hours to react. Ben Cartwright-Cox, creator of the BGP Tools suite, called the lapses “silly, preventable mistakes.”

The second is the absence of code signing. Softaculous states it plainly in its advisory: the Virtualizor update clients did not cryptographically verify packages. A modified package was therefore not rejected on any basis. This is the layer that should have made the hijack harmless: without signatures, whoever controls the route controls the code.

The indicator of compromise to hunt for

Softaculous cannot produce a definitive list of affected servers, precisely because update traffic was diverted to the attacker and no logs exist on the vendor side. It therefore recommends treating every Virtualizor server as in scope. The published indicator is an unusual systemd service:

# 1. The malicious service reported by Softaculous
ls -l /etc/systemd/system/java-jre-update.service
systemctl list-unit-files | grep -i java-jre-update
systemctl status java-jre-update 2>/dev/null

# 2. If present: pivot credentials before auditing anything else
#    - revoke and restrict Virtualizor/Softaculous API keys
#    - audit authorized SSH keys, accounts, and cron jobs
#    - inspect outbound connections

# 3. Quick audit of recent activity
last -20
crontab -l
cat /root/.ssh/authorized_keys

The presence of this service is not proof of compromise, but it triggers an immediate credential pivot and a full audit: SSH keys, accounts, scheduled tasks, and outbound connections. Users who accessed the Softaculous client area or entered payment details during the window should reset their passwords and watch their card statements.

The vendor’s response

Softaculous released Virtualizor 3.2.9.9 on September 1, 2026, shipping a “Security Analyzer” tool in the admin panel. The vendor also says it plans to implement cryptographic signing for all software packages and migrate to more robust infrastructure. Those are the right two answers, but they arrive after the fact: code signing is a baseline requirement for an update channel, not a fix you discover on the occasion of an incident.

The contrast with the state of the art is stark. Serious ecosystems — Debian, Arch, the npm and PyPI registries — sign their artifacts, and clients verify the signature before executing anything. A VPS management panel that drives hypervisors without that layer is an anomaly in 2026, not an acceptable limitation.

What RPKI does not fix

The incident should correct a misconception: RPKI ROV (Route Origin Validation) is not protection against this kind of attack when the ROA is permissive. It blocks a prefix from being announced by an unauthorized origin; it says nothing about the legitimacy of the content delivered through a valid route. Two layers are missing, and they are the ones that would have contained the incident.

The first is ASPA (Autonomous System Provider Authorization), still thinly deployed, which validates the legitimacy of the full path rather than just the origin. The second is announcement monitoring: Softaculous, Hetzner, and Zet.net did not notice the hijack until it had been pulsing on and off for 22 hours, for lack of monitoring their own prefixes. An operator that announces blocks must watch for their appearance in the global routing table — it is the simplest signal to instrument and the first one that failed here.

A twenty-year-old vector returning through negligence

Prefix hijacking is not new — it has accompanied the internet since its early days, when BGP ran on trust alone. The documented examples span the full actor spectrum: state-linked groups, such as the rerouting of financial traffic attributed to a Russian telecom in 2017, or mercenary operations, such as Hacking Team in 2015 hijacking IPs it did not own. The most telling case remains 2022: three hours of inaction by Amazon were enough for attackers to hijack the giant’s addresses, host a smart contract, and siphon roughly $235,000 in bitcoin from users of the Celer Bridge.

What changes in the Softaculous case is the target: no longer cryptocurrency or one-off espionage, but a software update channel. A BGP hijack is no longer used only to steal traffic — it is used to manufacture trust, then sell it in the form of an update. That is a change in nature, not just in scale.

Verdict

If you run Virtualizor, hunt for the java-jre-update.service right now, rotate your API keys and credentials, and upgrade to 3.2.9.9. Do not treat the absence of the service as cleanliness: an attacker may have wiped their tracks. Audit anyway.

If you operate an AS or a hoster, deploy RPKI ROV and add announcement monitoring — but do not stop there: demand code signing from every vendor whose updates you distribute, and refuse unsigned channels. A valid route is necessary, not sufficient.

If you consume automatic updates in production, the lesson is universal: pin versions, verify signatures, and treat every update channel as an attack surface in its own right. The next vendor without code signing is not a hypothesis — it is a list of servers waiting to be hit.

References

• Hackers push malicious Virtualizor update in BGP hijacking attack — BleepingComputer, September 1, 2026
• BGP hijack infecting networks caused by a comedy of errors that’s not funny at all — Ars Technica, September 2, 2026
• BGP Hijack Delivers Malicious Virtualizor Update That Establishes Persistent Root Access — The Hacker News, September 2, 2026
• Latest BGP hijack targets hosting software vendor — Kentik, Doug Madory
• Security Incident: BGP Hijacking — Virtualizor (Softaculous), September 1, 2026