The upgrade came from the correct source. It had a valid certificate, issued by an actual authority, and not a single client reported any problem. Everything that the software was able to check turned out alright. Yet, the software package installed one more key to the root user.
What is BGP hijacking? BGP hijacking is an incident in which an organization proclaims ownership of certain IP address space that does not belong to them. Since the routers will accept this information based mostly on trust, all of the traffic will end up in the wrong place.
Thirty-Three Hours On A Borrowed Route
Announcing of AS62390 of 162.55.80.0/24 happened on August 28, 2026 at 20:57 UTC. This address block belonged to Hetzner. Announcing came through transit service with Hetzner’s AS24940 announced in the path and made it appear much more legitimate than it really was.
Address block contained Softaculous update and billing services, including the domains of the Virtualizor hypervisor management solution. Packets destined for these systems were delivered to attacker’s server.
Hetzner announced an alternative route the next day morning, and diversion rate reduced almost to zero during 11 hours. After that, another wave of attack started and lasted until 06:10 UTC on August 30 when the spoofing route got withdrawn.
Reach of the attack was not low. In time of the waves, 72% out of 368 RIPE collector peers suffered from diverted packets.
The Certificate That Proved The Wrong Thing
This is why this particular event deserves consideration. The attacker has not stolen any certificate nor has he forged one. Instead, a legitimate certificate has been issued by the public authority for 26 domains which did not belong to him.
Automation of the issuance process involves checking whether or not the entity requesting the certificate controls the domain in question. The public authority initiates the challenge and waits for the response to be delivered. The traffic involved in the verification process went through the compromised path.
This is why the verification procedure took place correctly at that time since the attacker had actually controlled the destination for the traffic of the domain in question. This is exactly what the verification process should have verified.
Thus, a perfectly valid but totally misleading certificate was obtained. The process of HTTPS operation was carried out in accordance with its specification requirements.
The Lock Was Real. The Address Was a Lie.
What Landed On The Hypervisors
All installations of Virtualizor that performed the update check during a diverted period would get the malicious package. The update client would execute the package with root permissions.
The payload followed the usual list of actions. It would inject an attacker-controlled SSH key to the root account and create an additional account called proxyuser. Then came the installation of Java 17 version and the systemd service called java-jre-update.service located at /etc/systemd/system/.
One hosting company openly admitted that it discovered the attack and identified the same changes on 5 out of 34 hypervisor nodes running Virtualizor. In addition to that, it noted a successful password-based SSH login to proxyuser and no tampering with the customers’ VMs.
Softaculous admitted that the malicious package did reach some limited installations and not the general user base. Moreover, Softaculous cannot provide the definitive list of compromised servers as there are no logs on the server side.
The One Control That Was Missing
The core of the problem is a simple lack of verification that caused the result. The vendor himself described the issue the vendor’s clients were not verifying the packages through cryptography, thus even if some modified package were delivered to them, it would not be considered bad by their system.
The problem could have been solved through signing a package without a signature from the vendor is automatically invalid and does not work upon reception regardless of whether it came from the real server or not.
Softaculous has since shipped version 3.2.9.9 with a mitigation and analysis tool. Code signing for all packages is committed as a subsequent change. We have examined poisoned-update supply chains before, in the Axios npm compromise.
When Every Trust Signal Agrees And Is Wrong
Consider what was encountered by the detection mechanism, a perfectly valid updater running in a timely manner, reaching out to the legitimate domain of the vendor over a secured connection and installing a package. Good reputation check, good domain intelligence check.
That kind of behavior is not only normal it’s the intended behavior. It is built into all Windows endpoints in an enterprise environment.
The Execution Governance framework recognizes the true nature of the problem. Instead of checking whether installation behavior was malicious, the kernel level enforcement mechanism asks whether this particular code has been verified. Unseen package does not have such verification, no matter what domain it originates from.
Unknown code executes through Kernel API Virtualization mechanism, not unrestricted execution. File write operations get virtualized, registry access gets isolated. No matter how nicely the payload was delivered through the update channel, it still has to go through Kernel API Virtualization.
Conclusion: The Update Was Trusted. The Package Was Never Proven.
The defining lesson from the Virtualizor incident is not that TLS failed. TLS worked. The updater reached an address that routing presented as the vendor, received a technically valid certificate, established an encrypted connection, and downloaded an update through the normal workflow.
The missing trust decision was attached to the file itself.
During the BGP hijack, traffic destined for Softaculous infrastructure could be redirected to an attacker-controlled server. Because Virtualizor clients were not independently verifying update packages with a publisher signature, a malicious package delivered through that redirected path could still be accepted and executed with root privileges. The payload then added an attacker-controlled SSH key, created the proxyuser account, and established a systemd service for persistent access.
That distinction matters far beyond this incident. Transport security establishes properties about a connection. It does not prove that every file received through that connection was produced by the software publisher. When routing, mirrors, update infrastructure, or another delivery dependency is compromised, package integrity must survive independently of the path.
Why This Threat Matters
- Every visible trust signal could look normal. The updater was legitimate, the domain was correct, HTTPS succeeded, and the certificate was valid.
- Routing became part of the software supply chain. A network-layer trust failure changed where update requests arrived without requiring compromise of the vendor’s update client.
- TLS could not answer the package-integrity question. A secure connection to the wrong destination does not establish who produced the downloaded file.
- Root execution amplified the failure. Once accepted by the updater, the malicious package inherited the privileges required to create accounts, modify SSH access, and establish persistence.
- The receiving system had little evidence of the diversion itself. The network path could return to normal while the changes made by the malicious update remained.
- Package signing changes the trust boundary. A package whose publisher signature cannot be validated can be rejected regardless of which network path delivered it.
Where Defensive Control Must Operate
The first control must be package-level cryptographic verification. Update clients should verify that the publisher signed the exact artifact before installation, so trust remains attached to the package rather than the route used to retrieve it.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform provides an additional execution boundary on supported managed systems. If an unseen or untrusted package reaches the host through a poisoned update path, Execution Governance governs what that unknown execution may do at runtime before trust exists.
The two controls solve different problems: package signing verifies provenance, while Execution Governance limits what untrusted execution can do when upstream trust still fails.
Verify the Artifact, Not the Route
Softaculous has already added incident-specific remediation tooling and committed to package signing. Operators should still examine affected Virtualizor systems for unauthorized SSH keys, unexpected accounts, the java-jre-update service, and other persistence associated with the malicious package.
The architectural lesson is simple. A secure delivery channel cannot substitute for verifying what was delivered. When the network lies, trust has to survive the journey.
