Softaculous BGP Hijack Served Malicious Virtualizor Update, Planting Persistent Root Access

A week after some Softaculous customers unknowingly pulled a poisoned Virtualizor update, the company has published a minute-by-minute reconstruction of the incident, and the mechanism should unsettle anyone who trusts an auto-updater. For roughly 33 hours between August 28 and August 30, 2026, attackers hijacked the Border Gateway Protocol (BGP) routes for a block of Softaculous IP addresses, stood up a server behind a valid TLS certificate for Softaculous domains, and served a malicious Virtualizor update that established persistent root access on the hosts that installed it. No browser warning fired. No signature check failed, because there was no signature check.

Softaculous makes an auto-installer used across web hosting, and Virtualizor is its virtual private server (VPS) management panel, so a root-level compromise of a Virtualizor host is a compromise of every VPS running on it. The company says only a small number of installations took the malicious package, but it cannot produce a definitive list, and at least one hosting provider has already reported that five of its thirty-four Virtualizor nodes were hit. The Hacker News and SecurityWeek both reported the reconstruction on September 2, drawing on the vendor’s incident advisory.

This is a supply-chain attack, but not the kind most software defenses are built to catch. Nothing in Softaculous’s build pipeline was breached. The attack lived one layer down, in the internet’s routing table, and that is what makes it worth studying.

A Supply-Chain Attack That Lives in the Routing Table

The novel part of this incident is where it happened. According to Softaculous, at approximately 20:57 UTC on August 28, the network AS62390 (identified as NexonHost) began announcing 162.55.80.0/24, a slice of German host Hetzner’s address space (AS24940), through transit provider AS6204 (Zet.net). That announcement was more specific than Hetzner’s normal 162.55.0.0/16 route, and a more-specific route wins under standard BGP selection, so essentially every network that accepted it started sending Softaculous-bound traffic to the attacker. The hijacker kept Hetzner on the path tail as the apparent origin, which helped the route look legitimate to the rest of the internet.

Softaculous reconstructed the whole thing from public RIPE routing data rather than its own logs, because the malicious traffic never reached its servers. At peak, the company measured roughly 72 percent of route-carrying vantage points diverted to the attacker. The route also flapped hard, with about 10,600 withdrawals across the window, and there were two sustained waves separated by an 11-hour lull when Hetzner briefly announced the /24 directly. That intermittency is why only a handful of update checks happened to land on the malicious server and complete: a Virtualizor host was exposed only if its update check fell inside a diverted interval.

There is a defender lesson in the cleanup, too. Softaculous says Hetzner did not proactively notify it of the hijack, and that Hetzner’s effective fix, announcing the /24 directly, only took hold around 08:50 UTC on August 29, roughly 12 hours after the hijack began, and only after Softaculous escalated repeatedly. If an incident plan quietly assumes an upstream provider will catch a route leak on its customers’ behalf, this event argues the other way: detection and escalation may land on you, and the clock runs while you wait.

How a Genuine Certificate Defeated the Warning

The attackers did not forge or steal a certificate. They obtained a real one. Because the hijack also captured the traffic that certificate authorities use to confirm domain ownership, the attacker’s server was able to pass Let’s Encrypt’s automated domain-control validation and receive a technically valid TLS certificate for Softaculous domains. Connections riding the hijacked route therefore showed no certificate warning at all. The advisory lists 26 covered names across Softaculous products, including virtualizor.com, api.virtualizor.com, and files.virtualizor.com.

This is the detail defenders should sit with. TLS proves you reached the server your network routed you to. It does not prove that server is who it claims to be when the route itself is the lie. Softaculous says it reported the fraudulently issued certificate to Let’s Encrypt for revocation. The certificate authority had not publicly commented on the issuance as of September 2, and the exact certificate-transparency record was not detailed in the advisory. On the question of how the valid certificate was obtained, we treat it as answered: this was not a CA breach or a classic mis-issuance, but domain validation performed honestly against a dishonest route.

The fraudulent certificate was also broad. Per the advisory’s Appendix A, it covered 26 hostnames spanning Softaculous, Webuzo, SitePad, Backuply, and other products, not just Virtualizor, so any client that reached one of those endpoints during the window could have talked to the impostor without a warning. Alongside revocation, Softaculous says it notified network operators and national CERTs, preserved evidence, and is moving to new infrastructure. The transferable control for everyone else is cheap: watch Certificate Transparency logs for unexpected issuance against your own domains, because a rogue certificate is logged there whether or not you are the intended target.

What “Persistent Root Access” Looked Like

On a host that completed an update while diverted, the malicious package did what a signed one never should. Softaculous put the root cause plainly: “Our product update clients did not yet cryptographically verify update packages, so a modified package would not have been rejected on that basis.” Without signature verification, a valid TLS session was the only gate, and the hijack had already opened it.

The defender-relevant indicators, drawn from the vendor advisory and the affected provider’s report, are specific. The package modified core Virtualizor files, a root-owned scheduled task executed the injected code, an attacker key was added to the root account, a Java runtime was installed and used to fetch and run a payload as root, and persistence was established through a systemd unit at /etc/systemd/system/java-jre-update.service. One provider also observed an unauthorized account named proxyuser and a successful SSH login from 193.32.127[.]248, with the payload beaconing to attacker domains cdn.nerat[.]cc and connect.ne-rat[.]xyz. Those are hunt targets, not a recipe. The point is that a single completed update check could hand over root on the whole node.

Who Is Confirmed Affected

The most important operational sentence in the advisory is an admission of uncertainty: Softaculous cannot produce a definitive list of affected servers, because the malicious responses came from the attacker’s system and never touched the company’s logs. So every Virtualizor operator is in scope for checks, whether or not they think they updated during the window.

Only one victim has been named so far, and it named itself. AlbaHost, a provider posting in a LowEndTalk thread, wrote that five of its thirty-four Virtualizor hypervisor nodes carried the same malicious modifications. The CyberSignal has not independently verified that account, and no other specific victim hosts have been confirmed. Softaculous had not published a malicious-package filename or hash, or a list of affected update channels, as of September 2, so the true blast radius remains open. The company also warns that client-area and billing sessions during the window may have been diverted, though it has reported no confirmed theft of payment data.

For the client-facing side, the guidance is concrete. Anyone who logged into the Softaculous client area or entered card details between August 28 at 20:57 UTC and August 30 at 06:10 UTC should reset that password, change it anywhere it was reused, regenerate their Client Center API keys, and review card statements. Softaculous notes it does not process cards from its own servers, so payment data is handled at the gateway, but a login session that was diverted to the attacker is still worth treating as exposed rather than assumed safe.

What Operators Should Do Now

Softaculous shipped Virtualizor 3.2.9.9 (Patch 9) with a security scanner on September 1 and says package code signing is still to come. The scanner checks for known indicators, so it is a starting point, not proof of a clean host. The checklist below tracks the vendor guidance and the routing-layer lessons.

The routing-layer items matter beyond this one vendor. The same pattern, a hijacked prefix plus a validly issued certificate, has surfaced before against hosting and content providers, and the defenses are unglamorous: RPKI route-origin validation, monitoring for unexpected announcements of your prefixes, and, on the software side, signed update packages that a client verifies before installing. For related supply-chain reading, see our coverage of the Nextend backdoor that reached 900,000 sites and AWS’s attribution of the axios npm hijack.

My Read

My read: a valid TLS certificate plus a BGP hijack defeats the entire update-trust chain, which makes this a routing-layer supply-chain attack, not an application one. Every control hosting operators lean on here, HTTPS, a trusted vendor domain, an auto-updater, assumes the network underneath is honest. When the route is the lie, TLS faithfully secures your connection to the wrong server, and an unsigned update walks straight in. The fix is not vigilance. It is signature verification on packages and route-origin validation on prefixes, so that neither trust anchor has to stand alone. (That is my assessment. The reconstructed facts above are Softaculous’s, corroborated by public routing data.)

Primary documents

• Softaculous / Virtualizor incident advisory, “Security Incident: BGP Hijacking”
• Virtualizor 3.2.9 (Patch 9) release note
• The Hacker News: BGP hijack delivers malicious Virtualizor update
• SecurityWeek: Malicious Virtualizor update served via BGP hijacking

Updated September 2, 2026: Softaculous’s investigation into whether other products were affected remains open. We will update as the vendor publishes package hashes or an affected-channel list.