Hackers hijacked internet routing to push a poisoned Virtualizor update
Softaculous says attackers rerouted its update servers for 33 hours, delivering a malicious update to a small number of hosting providers running Virtualizor.

Key points
- Attackers hijacked internet routing for Softaculous update servers between 20:57 UTC on 28 August and 06:10 UTC on 30 August 2026.
- A malicious Virtualizor update reached a small number of installations that checked for updates during the 33-hour window.
- Softaculous released Virtualizor 3.2.9.9 on 1 September with a new Security Analyzer tool in the admin panel.
- Customers who used the Softaculous client area or entered card details during the window are told to reset passwords and monitor statements.
- The vendor plans to add cryptographic signing to all future software packages.
Criminals broke into the update system for Virtualizor, a control panel that hosting companies use to sell and manage virtual private servers, and pushed a booby-trapped update to some of its customers.
The attack, first reported by BleepingComputer, worked by tricking the internet itself. For about 33 hours, traffic meant for the vendor's servers was quietly steered to machines run by the attacker.
How did the hackers get in?
They used a technique called BGP hijacking. BGP, short for Border Gateway Protocol, is the system internet providers use to tell each other which routes lead to which addresses. Think of it as the internet's road signs.
An attacker put up fake road signs pointing to a block of Softaculous IP addresses hosted at Hetzner, a large European hosting firm. Other networks accepted the fraudulent route and started sending traffic the wrong way.
That traffic included update requests from Virtualizor servers, plus visits to the Softaculous client and billing portal. The window ran from 20:57 UTC on 28 August 2026 to 06:10 UTC on 30 August 2026. Any Virtualizor server that phoned home for an update during those 33 hours could receive a poisoned package instead of the real one.
How many customers were affected?
Softaculous says only a small number. The vendor states: "We have confirmed that a malicious Virtualizor update package was delivered to a small number of installations that checked for updates while their traffic was being diverted. This affected a handful of servers rather than the general Virtualizor user base."
Because the requests never reached the real servers, Softaculous has no logs of exactly who received the bad update. Administrators have to check for themselves.
What should Virtualizor operators check?
Softaculous is telling admins to look for a specific file on their systems:
| Item | Value |
|---|---|
| File to check | /etc/systemd/system/java-jre-update.service |
| Attack window start | 28 Aug 2026, 20:57 UTC |
| Attack window end | 30 Aug 2026, 06:10 UTC |
| Fixed version | Virtualizor 3.2.9.9 (released 1 Sep 2026) |
If that file is present, treat the server as compromised. The vendor recommends rotating API credentials, tightening what those credentials can do, and auditing for unauthorised SSH keys, user accounts and outbound network connections that shouldn't be there. SSH keys are digital keys that let someone log in without a password; attackers often plant their own so they can return later.
What about ordinary customers?
Anyone who logged in to the Softaculous client area, or typed payment details into the billing portal during the attack window, should reset their password and watch their card statements. If traffic was flowing through the attacker's servers, what users typed could have been captured.
Routing has been restored. The fraudulent TLS certificate, the small file that proves a website is really who it claims to be, has been reported for revocation. Softaculous says its investigation is continuing and no other products appear to have been touched.
This one's worth watching for two reasons. First, BGP hijacking at the supply-chain layer is rare enough that most hosting operators won't have drilled for it. Second, the vendor's promise of cryptographic signing is the right fix, but it's a promise, not a shipped feature. Until that signing lands, update verification rests entirely with the operator. We covered a similar poisoned-update scenario in August, when a promotional feed was used to push malicious code into WordPress admin dashboards: the delivery mechanism differs, but the exposure window logic is identical.



