For roughly 22 hours across two late-August nights, internet traffic bound for the infrastructure of Softaculous, the company behind the app auto-installer of the same name and the Virtualizor VPS management panel, was intermittently diverted to a server controlled by an attacker. The company’s security advisory, published August 31, reconstructs the incident from public routing data and does not soften it: the attacker held a technically valid TLS certificate for the company’s domains, so diverted connections showed no warning, and a malicious Virtualizor update was delivered to a small number of servers that checked for updates at the wrong moment.
Key facts
- Window: an unauthorized route for 162.55.80.0/24, a block of Hetzner address space hosting Softaculous systems, was announced from August 28, about 20:57 UTC, in two waves ending August 30, about 06:10 UTC.
- Reach: when the hijacked /24 was broadly propagated, roughly 72 percent of RIPE’s 368 routing vantage points sent traffic for the block to the attacker, with snapshots as high as 272 of 368; all 368 carried the hijacked route at some point.
- Payload: a malicious Virtualizor update reached a small number of servers; the published indicator of compromise is a systemd unit named java-jre-update.service.
- Stealth: a valid Let’s Encrypt certificate, issued because the CA’s checks followed the hijacked route, covered 26 domain names by our count.
A /24 Beat Hetzner’s /16, With Hetzner’s Own Number Left as Cover
The mechanics were textbook BGP hijacking with one refinement. At approximately 20:57 UTC on August 28, the network AS62390 (NexonHost) began announcing 162.55.80.0/24, a slice of Hetzner’s address space that holds Softaculous systems including the software update endpoint and the client billing area, without authorization, through the transit provider AS6204 (Zet.net). Because a /24 is more specific than Hetzner’s normal announcement of the surrounding /16, it won route selection on every network that accepted it. The refinement: the hijacker kept AS24940, Hetzner’s own number, at the tail of the route as the apparent origin and never appeared as the origin itself.
The advisory reconstructs the spread from RIPE’s Routing Information Service, whose 368 collector peers approximate the internet’s view of a route. Every one of the 368 carried the hijacked route at some point. Whenever the unauthorized /24 was broadly propagated, essentially every peer that held it sent its traffic toward the attacker, typically about 72 percent of the full set, with the highest snapshots showing 272 of the 368, or 73.9 percent; in the advisory’s words, this was “a broadly visible hijack, not a localized one.” The route was also highly unstable, with roughly 10,600 withdrawals recorded across the window as flap dampening repeatedly suppressed it, which is why the diversion was intermittent rather than continuous for any single server.
A Valid Certificate, Because the CA’s Checks Took the Same Road
The hijack defeated the reassurance users are trained to rely on. The attacker’s server obtained a publicly trusted TLS certificate from Let’s Encrypt because the certificate authority’s automated domain-ownership validation was itself routed through the hijack. Diverted connections therefore showed no browser or client certificate warning. Let’s Encrypt, by its own documentation, validates domain control from multiple network perspectives in parallel precisely to make attacks of this kind harder; that a certificate was issued anyway fits the advisory’s finding of how broadly the false route propagated. By our count of the advisory’s appendix, the certificate covered 26 names across the company’s portfolio, spanning softaculous.com, virtualizor.com, webuzo.com, sitepad.com, ampps.com, backuply.com, pagelayer.com and popularfx.com.
The advisory says active interception was independently confirmed on the morning of August 29, when a host on the diverted route answered for Softaculous domains using the fraudulently obtained certificate; the impostor machine at 162.55.80.8 carried the reverse DNS name server.softaculous.com.
One Poisoned Update, and No Definitive List of Victims
The payload landed where the trust chain was weakest. Virtualizor’s update clients, the advisory states plainly, “did not yet cryptographically verify update packages,” so a modified package would not have been rejected on that basis. A malicious update was delivered to installations whose update checks happened to land inside a diverted interval; the vendor believes this affected a handful of servers rather than the general user base. But because the malicious responses were served from the attacker’s system and never touched the vendor’s own logs, the company writes that it “cannot produce a definitive list of affected servers” and asks every Virtualizor operator to treat their server as in scope.
The advisory’s main checks:
- Check for the indicator of compromise: a systemd unit at /etc/systemd/system/java-jre-update.service. If it is present, do not delete it; contact the vendor so evidence is preserved. The vendor has also published a script, virtualizor_security_scan.sh.
- Rotate and restrict Virtualizor API keys, and remove any key you do not recognize.
- Audit access: unknown SSH keys, new accounts, unexpected cron jobs, unexpected outbound connections.
- Reset Softaculous client-area passwords and regenerate NOC API keys as a precaution; sessions and payment details entered during the window may have been diverted. The company notes card payments are processed at external gateways, not on its servers.
For the rest of the portfolio, Webuzo, Softaculous, Backuply and SitePad included, the company says it has found “no reports or evidence of any compromise involving Softaculous or any of our other products,” with the investigation ongoing.
Twelve Hours to a Countermeasure, and a Second Wave Anyway
The immediate countermeasure was for Hetzner to announce the /24 directly, which restored legitimate routing within minutes. In the vendor’s account, it did not come quickly. The advisory states that Hetzner “did not proactively notify us of the hijack” and that the countermeasure took effect at about 08:50 UTC on August 29, roughly 12 hours after onset, after Softaculous reported the hijack and, in its words, escalated repeatedly. The relief did not hold: later that day both the hijacked and the corrective routes were withdrawn, and around 20:00 UTC the unauthorized announcement resumed for roughly ten more hours before being withdrawn for good early on August 30. Per the advisory, Hetzner acknowledged the incident only after the company contacted it again on August 31, the day both incident reports were published.
Three Layers of Trust, and One Wrong Road Under All of Them
The wider reading is ours: the incident shows how much of the hosting stack quietly defers to routing. Certificate validation trusted the network path, so the certificate followed the hijack. Update clients trusted the certificate, so the payload followed it too. For hosting providers, the practical questions land in two places: at software vendors, whether update packages are cryptographically signed and verified by the client, so that a tampered package is rejected, and at upstream networks, who monitors prefix announcements, and how fast an escalation moves outside business hours. The minute-by-minute reconstruction here came from public routing data, not from anything running on the affected servers, and that data is public: routing feeds and automated route-alerting services can watch it continuously.
About the Data
Both vendor documents, the Softaculous incident update and the detailed advisory on the Virtualizor blog, were published on August 31, 2026 and read in full. The routing figures are the advisory’s own reconstruction from RIPE’s public Routing Information Service; we spot-checked two of its ten-minute snapshots against the same public RIPE Stat data, and both matched, including the route path that keeps Hetzner as the apparent origin. All times are UTC and approximate, as the advisory notes. The note on multi-perspective validation comes from Let’s Encrypt’s official documentation. Hetzner’s role is reported as the vendor describes it; the closing reading of the incident is ours.
