Security Incident Bgp Hijacking

Between 28 August 2026 at approximately 20:57 UTC and 30 August 2026 at approximately 06:10 UTC , a block of IP addresses used by Softaculous services ( 162.55.80.0/24 , part of our infrastructure at Hetzner) was affected by a BGP hijack : an unauthorized announcement of that address space by an unrelated network, which diverted internet traffic destined for those addresses to a server operated by an attacker. The attacker obtained a technically valid TLS certificate for our domains, so connections affected by the hijack showed no certificate warning.

The affected addresses served, among other systems, our software update endpoint , our client area / billing site.

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 malicious responses were served by the attacker’s system and never reached our own logs, we cannot produce a definitive list of affected servers, so every Virtualizor operator should carry out the checks in the If you run Virtualizor section. We have not identified a malicious package for any other product; that investigation is ongoing.

Routing has been fully restored. We have reconstructed the incident minute-by-minute from public routing data; the complete measurement table is included below.

Traffic between networks on the internet is routed using BGP (Border Gateway Protocol), a system that has historically relied on networks trusting one another’s route announcements. In a BGP hijack , a network announces IP address ranges it does not control, and traffic for those addresses is drawn toward it.

At approximately 20:57 UTC on 28 August 2026 , the network AS62390 (NexonHost) began announcing 162.55.80.0/24 — a portion of Hetzner’s address space containing IP addresses for a number of Softaculous systems — without authorization, routed through the transit provider AS6204 ( Zet.net ) . This announcement was more specific than Hetzner’s normal announcement of the surrounding block ( 162.55.0.0/16 ), so under standard BGP route selection it took precedence on every network that accepted it . The announcement retained AS24940 (Hetzner) on the AS path as the apparent origin.

The attacker’s server was able to obtain a valid TLS certificate from a public certificate authority (Let’s Encrypt) for our domains, because the certificate authority’s automated domain-ownership validation was also routed through the hijack. Connections affected by the hijack therefore did not show a browser or client certificate warning. The certificate covered domains across our products, including virtualizor.com , api.virtualizor.com and files.virtualizor.com ; the full list is in Appendix A.

All times UTC. Start and end times are corroborated by public RIPE routing data, not only by provider reports.

How widespread it was, and how we measured it

Method. RIPE’s Routing Information Service (RIS) operates 368 collector peers — a sample of mostly large transit and internet-exchange networks around the world. For each 10-minute mark across the incident we retrieved the reconstructed routing table for 162.55.80.0/24 and counted, among the peers that held a route to the prefix at that moment:

Diverted — best path traverses AS62390 (the hijacker);

On clean /24 — best path is a legitimate /24 (Hetzner origin, no AS62390); this only exists once Hetzner began announcing the /24 directly as a countermeasure;

Peers with no /24 route fell back to Hetzner’s normal 162.55.0.0/16 and were not diverted.

The of RIS peers whose best path traversed the hijacker is the standard proxy for the of the internet whose traffic to this address range was sent to the attacker. It is a routing-topology measure, not a byte count.

What this means in practice. Whenever the unauthorized route was propagating, a server had roughly a 72% chance (by this proxy) that its network was sending traffic for 162.55.80.0/24 to the attacker — this was a broadly visible hijack, not a localized one, because a more-specific announcement beats the legitimate route everywhere it reaches. However, the route flapped continuously, so for any individual server the diversion was intermittent across the roughly 22 hours the hijack was active, and there was an ~11-hour window mid-incident with almost no diversion. A Virtualizor server received the malicious package only if an update check happened to land during a diverted interval and completed — which is why only a small number of installations were affected.

Findings: full BGP-state measurements (10-minute resolution)

Reconstructed from RIPE RIS via the RIPE Stat bgp-state API, one snapshot every 10 minutes. Column definitions

Time (UTC) — snapshot time ( MM-DD HH:MM ).

Peers with route — RIS collector peers (of 368) holding any route to 162.55.80.0/24 .

Diverted (AS62390) — of those, how many had a best path through the hijacker.

On clean /24 — of those, how many had a legitimate /24 best path (Hetzner’s countermeasure announcement).

% of routed peers — Diverted / Peers-with-route.

% of all 368 RIS — Diverted / 368 (lower-bound proxy for of the internet diverted).

How to read it. Rows aligned to 00:00 and 08:00 UTC are the most reliable (RIS takes a full table snapshot every 8 hours); values between those points can under-count because the route was flapping so hard. Multi-row plateaus and the 8-hourly rows are ground truth; isolated single-row spikes or dips are measurement noise or momentary flap states. A row showing 1 diverted / 1 with route during a wave means the route was suppressed almost everywhere at that instant (flap dampening), not that the hijack had stopped.

Hetzner did not proactively notify us of the hijack. Their effective mitigation — announcing the /24 directly — took effect at approximately 08:50 UTC on 29 August, 12 hours after onset, and only after we contacted them on 31st August did they acknowledge the same.

Software updates — the malicious Virtualizor package

During the incident window, a Virtualizor installation whose traffic was diverted could have received a malicious update package from the attacker’s server. Our product update clients did not yet cryptographically verify update packages, so a modified package would not have been rejected on that basis. We believe only a small number of servers were actually affected, but we cannot produce a definitive list, so please treat every Virtualizor server as in scope for the checks below.

Known indicator of compromise: a systemd unit at /etc/systemd/system/java-jre-update.service (and a corresponding enabled or running java-jre-update service).

If you run Virtualizor — do this now

Check for the indicator of compromise. Look for /etc/systemd/system/java-jre-update.service . If it is present, your server was affected — do not simply delete it; us .

Rotate and restrict Virtualizor API credentials. In the Virtualizor master (admin) panel, reset all API keys, restrict API access to trusted IP addresses, and remove any API key you do not recognize.

Audit access. Review the server for unknown SSH keys, new user accounts, unexpected scheduled tasks or cron jobs, and unexpected outbound connections. Restrict SSH to trusted IP addresses.

You can also run a small cleaning script we have made :

If you find signs of compromise, support before remediating so we can help preserve evidence.

Other products (Webuzo, Softaculous, Backuply, SitePad, etc.)

We have not identified a malicious package for these products. As a precaution, if one of these servers performed an update check during the incident window, verify the server for anything suspicious and us if you find anything suspicious.

Billing and client area

If you logged into softaculous.com/clients or entered payment details between 28 August ~20:57 UTC and 30 August ~06:10 UTC , your session may have been diverted to the attacker’s server.

Reset your client-area password now. If you reused that password anywhere else, change it there too.

Review recent account activity, and if you entered card details during the window, review your card statements. We dont process cards from our servers and its all processed at payment gateways.

On our side, we are invalidating client-area sessions from the affected period.

client Center API keys

As a precaution, regenerate your API keys from and update them on your servers.

What we have done / doing

Launched a version of Virtualizor 3.2.9.9 with a mitigation tool for known exploits. More changes will come as well.

Reported the fraudulently issued certificate to Let’s Encrypt for revocation.

Reported the incident to the relevant network operators and CERTs, and preserved evidence.

Reconstructed the incident from public routing data (the measurement table above).

Will have the code signing mechanism in place for all packages.

Migrate over to a better infra.

If you have questions this incident or need help checking a server, us at . We will update this post as the investigation progresses.

Appendix A — certificate names

The fraudulently obtained certificate covered the following names:

a.softaculous.com , ampps.com , api.sitepad.com , api.softaculous.com , api.virtualizor.com , api.webuzo.com , backuply.com , files.ampps.com , files.sitepad.com , files.softaculous.com , files.virtualizor.com , files.webuzo.com , pagelayer.com , popularfx.com , server.softaculous.com , sitepad.com , softaculous.com , virtualizor.com , webuzo.com , , , , , , , .

Appendix B — methodology and data

Prefix: 162.55.80.0/24 (Hetzner; normally covered only by 162.55.0.0/16 ). softaculous.com resolved to 162.55.80.8 during the incident; the impostor host at that address carried the reverse DNS name server.softaculous.com .

Hijack path: origin AS24940 (spoofed / kept on the path tail), hop AS62390 (NexonHost), transit AS6204 ( Zet.net ). First unauthorized announcement observed at 2026-08-28T20:57:30Z , example AS path 20912 6204 62390 24940 .

Data sources: RIPE Stat bgp-state (10-minute snapshots), RIPE Stat bgp-updates and RIPE Stat / RIPE RIS bgplay (event stream, ~41,000 events, ~10,600 of them withdrawals), RIPE BGPlay visualisation ( ).

RIS peer set: 368 collector peers. All 368 carried the hijacked route at some point during the incident.

Reliability: bgp-state reconstructs from 8-hourly RIB dumps plus intervening updates. Snapshots aligned to 00:00 / 08:00 / 16:00 UTC are the most accurate; between-dump values can under-count visible peers during heavy flapping. Percentages are of the RIS peer sample and approximate the of internet networks affected; they are not a measure of traffic volume.