TL;DR
- what: An attacker falsely announced a block of Hetzner-hosted IP addresses belonging to Softaculous, diverted Virtualizor update checks and the client billing portal, and served a malicious update package.
- impact: A backdoored update reached VPS control panel hosts that run with root on hypervisor nodes, and the billing portal diversion exposed client area credentials and payment data entered during the window.
- fix: Update to Virtualizor 3.2.9.9, released September 1, 2026, and check every panel host for the file /etc/systemd/system/java-jre-update.service.
- who: Hosting providers and anyone running the Softaculous Virtualizor VPS control panel that performed an update check between 20:57 UTC on August 28 and 06:10 UTC on August 30, 2026.
For 33 hours, from 20:57 UTC on August 28 to 06:10 UTC on August 30, 2026, an attacker owned the route to Softaculous update infrastructure and used it to ship a malicious Virtualizor package. Any Virtualizor installation that ran an update check during that window was talking to the attacker, not to the vendor. Virtualizor is a VPS control panel: the software sits with root privileges on the nodes that create, provision, and manage customer virtual servers. One poisoned install is not one compromised server. It is potentially every VPS on that node, plus the API credentials and SSH keys the panel holds.
What happened
Softaculous confirmed that an attacker announced a route for a block of Hetzner-hosted IP addresses belonging to the company. BGP has no built-in check on who owns a prefix. When a network operator announces one, peers that accept the announcement start sending traffic there, and a more specific announcement wins. In this case the fraudulent route diverted two things at once: the software update systems and the client and billing portal.
With that traffic in hand, the attacker served a malicious Virtualizor update package to installations that checked for updates during the window. Softaculous characterizes the result as a small number of installations, and says this affected a handful of servers rather than the general Virtualizor user base. Treat that as an estimate rather than a count, for the reason covered below.
⚠️ Check this file on every Virtualizor host now — Softaculous published one indicator of compromise: /etc/systemd/system/java-jre-update.service. A systemd unit named after a Java runtime update has no legitimate reason to exist on a VPS control panel node. If it is present, treat the host and every VPS provisioned from it as compromised, not merely suspect.
The persistence choice tells you something about intent. A systemd unit survives reboots, starts before operator login, and runs as root by default. It is also the kind of name that survives a bored glance at a process list. Anyone auditing should not stop at that exact filename: list every unit file created or modified between August 28 and 30 and treat unfamiliar entries as leads.
The vendor cannot tell you whether you were hit
This is the part that changes your response plan. Because update requests were redirected away from Softaculous, the vendor has no server-side logs for the window. There is no list of affected customers to be published later, and no support ticket that will confirm your status. The company can tell you what the malicious package left behind, and nothing about who received it.
That pushes detection onto you. Pull your own firewall, proxy, or netflow records for connections from Virtualizor hosts to Softaculous update endpoints during the window. If your panel nodes checked for updates in that period, you were in scope regardless of what the vendor estimate says.
A valid certificate is not a valid package
A fraudulent certificate was issued during the incident and has since been reported for revocation. That detail is the whole lesson. Domain control validation proves you reached whatever answered for the hostname, and the attacker controlled the route, so the attacker could satisfy validation and obtain a working certificate. TLS confirmed the connection was encrypted to the party at the end of the hijacked path. It confirmed nothing about the package.
Signing is the control that survives a routing compromise — Cryptographic package signing with a key held offline is the one mechanism in this chain that a BGP hijack cannot forge. Softaculous says it will implement signing for all software packages going forward and migrate to better infrastructure. It did not have signing in place during this incident, which is why a hijacked route was enough to reach customer hosts.
Blast radius
Two separate exposures came out of one hijack. The update channel gave the attacker code execution on hosting infrastructure. The diverted client and billing portal gave the attacker whatever users typed into it. Softaculous advises that anyone who accessed the client area or entered payment information during the incident window reset passwords, review account activity, and monitor card statements. If your staff logged into that portal during the window, treat those credentials as burned and rotate them everywhere they were reused.
What to do now
- Update to Virtualizor 3.2.9.9, released September 1, 2026, and run the Security Analyzer tool that ships in the admin panel with it.
- Check every Virtualizor node for /etc/systemd/system/java-jre-update.service, then review all systemd units and timers created between August 28 and 30.
- Rotate Virtualizor API credentials, then restrict them by source IP rather than reissuing them wide open.
- Audit authorized_keys, local accounts, sudoers, and cron on panel hosts and on the guest VPS instances they provision.
- Review outbound connections from panel hosts for the incident window and for every day since, since a planted unit may still be beaconing.
- Reset passwords for anyone who used the Softaculous client area during the window, and notify customers who submitted payment data.
- Pull your own network telemetry for update checks in the window, because the vendor has none to correlate against.
The wider problem
Routing has been restored and the investigation continues, with no current indication that other Softaculous products were affected. That last point is provisional, not a conclusion, and it should be revisited as the vendor publishes more.
The uncomfortable part is how portable this technique is. Most software vendors publish updates over HTTPS from a handful of prefixes, with certificate validation as the only integrity check between vendor and customer. Against an attacker who can move traffic at the routing layer, that check evaluates to true for the wrong server. Ask every vendor whose code auto-installs in your environment two questions: are release artifacts signed with a key that never touches the build or distribution network, and are your prefixes covered by RPKI route origin authorizations with peers doing origin validation. A vendor that answers no to both is one BGP announcement away from this story.
Originally published on RedEye Threat Intelligence.
