A BGP hijacking attack redirected Softaculous and Virtualizor update traffic to an attacker-controlled server between August 28 and August 30, 2026, letting malicious Virtualizor packages reach a handful of installations. The short lesson is uncomfortable: HTTPS can prove you’re talking to a domain only if routing and certificate issuance haven’t been bent first. Update systems need signed packages, routing controls, and repository defenses working together.
What happened in the Softaculous BGP hijacking attack?
The incident centered on 162.55.80.0/24, a Hetzner-hosted IP range used by Softaculous infrastructure, including the Virtualizor update endpoint and Softaculous client and billing systems. According to Virtualizor and Softaculous, an unauthorized route announcement began around 20:57 UTC on August 28, 2026, and normal routing was restored globally around 06:10 UTC on August 30.
The unauthorized announcement involved AS62390, NexonHost, and transit provider AS6204, Zet.net. The legitimate origin was AS24940, Hetzner. Because the hijacked route was a /24, it was more specific than Hetzner’s broader 162.55.0.0/16 route, so many networks preferred the attacker-controlled path under the internet’s longest-prefix-match rule.
That sounds arcane. It isn’t. If your server asked for a Virtualizor update during the diverted windows, parts of the internet could send that request to the wrong place while the hostname still looked right.
BleepingComputer reported on September 1, 2026, that malicious Virtualizor update packages were delivered during the event. Virtualizor and Softaculous described the affected group as small, because only installations that checked for updates during the hijack and received malicious responses were exposed.
The timeline, with the numbers that matter
Virtualizor’s August 31, 2026 incident report split the event into two active waves. The first ran from about 21:00 UTC on August 28 to 08:50 UTC on August 29. The second ran from about 20:00 UTC on August 29 to 06:00 UTC on August 30, with withdrawal at roughly 06:10 UTC.
One useful calculation: the whole incident window lasted roughly 33 hours, but the two main active waves add up to about 21 hours and 50 minutes. That’s around two-thirds of the window. For defenders, that distinction matters because a single timestamp saying “the incident lasted 33 hours” can overstate continuous exposure while still understating the operational problem: update checks are automated, scattered, and easy to miss.
| 2026 event | Reported detail | Why it mattered |
|---|---|---|
| Aug. 28, ~20:57 UTC | AS62390 began announcing 162.55.80.0/24 | Traffic to affected Softaculous services could be diverted |
| Aug. 29, ~08:00–08:50 UTC | Virtualizor says active interception was independently confirmed | A diverted host answered for Softaculous domains with a valid certificate |
| Aug. 29, ~08:50 UTC | Hetzner began announcing 162.55.80.0/24 directly | Diversion dropped to zero within minutes, according to Virtualizor |
| Aug. 30, ~06:10 UTC | Unauthorized route withdrawn | Normal global routing was restored |
| Sept. 1, 2026 | Virtualizor 3.2.9 Patch 9 released | Added Security Analyzer in the Admin panel |
Virtualizor reported measuring the event with 368 RIPE RIS collector peers. Its single-source figures say 368 of 368 peers carried the hijacked route at some point, with a reported peak near 100% of route-carrying vantage points during active periods, a median of 266 peers, and roughly 10,600 route withdrawals during the window.
Use those measurements carefully. RIPE RIS peers are vantage points, not a census of every affected server. Still, they show the route leak wasn’t a tiny local oddity. It propagated widely enough that routine software update traffic became a delivery channel.
Why TLS did not save the update channel
A common misunderstanding is that HTTPS ends this kind of story. In the Softaculous case, the attacker reportedly obtained technically valid TLS certificates during the hijack because certificate-validation traffic was also routed to the attacker’s server. Virtualizor said the certificate covered domains including virtualizor.com, api.virtualizor.com, and files.virtualizor.com.
TLS protects the transport session: the connection is encrypted, and the certificate binds a name to a key under the certificate authority system. But if the process that proves domain control is itself fooled by a temporary routing diversion, the browser or update client may see no certificate error. Clean padlock. Bad destination.
Ars Technica reported in September 2026 that Let’s Encrypt said CAA account binding would have made certificate issuance “significantly more difficult” for the attacker. That’s a meaningful mitigation, not a magic shield. Certificate controls reduce the chance of fraudulent issuance; they don’t verify that the software payload is the one the vendor intended to ship.
The uncomfortable pitfall many postmortems skip: certificate monitoring after the fact can tell you a suspicious certificate existed, but it may not tell you which automated clients trusted it during a 20-minute or two-hour slice of a routing event. By then, your updater may already have run as root.
Package signing is the layer Virtualizor was missing
Virtualizor stated that its product update clients did not yet cryptographically verify update packages. That means a modified package would not have been rejected on package-signing grounds once the client accepted the HTTPS endpoint. Honestly, for server management software, that missing layer is the part that should make administrators wince.
A proper update design makes the client verify the payload independently from the connection. The client checks a vendor signature, a trusted signing key, signed metadata, or a pinned hash before installing. If the mirror, CDN, DNS path, or BGP route lies, the package still fails verification.
This is the same separation of duties security teams already apply to identity elsewhere. If you’re thinking about machine credentials and service identities, the broader problem is close to the one described in non-human identity management: automated actors make decisions at machine speed, so weak trust assumptions scale badly.
Hash verification alone can help, but only if the trusted hash comes from a channel the attacker can’t also modify. Signed metadata is stronger. The Update Framework, known as TUF, goes further with delegated roles, threshold signatures, expiration, and rollback protection, so a malicious mirror can’t simply replay an old vulnerable version or mix files from different releases.
Where BGP, RPKI, and ROV fit in the defense
BGP was designed for reachability among cooperating networks, not for proving moral ownership of every route announcement. A BGP hijacking attack abuses that trust by making the internet prefer an unauthorized path. The longest-prefix-match rule then does exactly what it was built to do: choose the more specific route.
RPKI and Route Origin Validation can limit unauthorized origin announcements when Route Origin Authorizations are strict and networks enforce them. In this case, Ars Technica reported, citing Doug Madory, that the forged AS path remained RPKI-valid because the ROA required origin AS24940 and allowed prefix lengths from /16 through /24. That edge case matters.
Translation: having RPKI isn’t the same as having a route policy that blocks every useful hijack shape. If a ROA allows a /24, and the path can be made to appear valid at the origin level, defenders may need additional monitoring, tighter maximum prefix lengths where possible, upstream filtering, and fast escalation with hosting providers.
For teams planning hosting and network exposure, route security belongs beside capacity and geography, not in a forgotten appendix. The same practical mindset applies when you plan a dedicated server deployment: know your provider’s routing controls, notification process, and emergency contacts before the outage or hijack happens.
What should Virtualizor operators check now?
Virtualizor and BleepingComputer both advise operators to check for /etc/systemd/system/java-jre-update.service as an indicator of possible compromise. Softaculous also advised client-area users to reset passwords if they logged in during affected windows. Since Virtualizor said malicious responses were served from the attacker’s system, the company couldn’t produce a definitive affected-server list from its own logs.
That creates an awkward reality: if your server updated during the window, absence from a vendor list doesn’t prove safety. You need local evidence.
- Check whether
/etc/systemd/system/java-jre-update.serviceexists, and preserve forensic evidence before deleting anything. - Review Virtualizor update activity and system logs covering August 28, 20:57 UTC, through August 30, 06:10 UTC, 2026.
- Install Virtualizor 3.2.9 Patch 9, released September 1, 2026, and run the Security Analyzer from the Admin panel.
- Rotate credentials that may have been used in affected Softaculous or Virtualizor client and billing sessions.
- Rebuild from known-good media if you find the indicator or can’t establish what ran during the diverted period.
Automated remediation is tempting, but don’t rush past evidence collection. If a management host is compromised, it may have credentials to guests, templates, storage, DNS APIs, or backup systems. Server control panels sit in privileged places.
Teams that already practice adversary simulation should add update-channel compromise to their scenarios. If you use autonomous testing, a useful next step is to model the same chain described in autonomous red teaming: route trust, certificate trust, package trust, and post-install persistence.
The real lesson: updates need layered distrust
A BGP hijacking attack like this one is not just a network story. It is a supply-chain story wearing a routing mask. The attacker didn’t need to breach every Virtualizor customer directly; the update mechanism did the distribution work for any client that asked at the wrong time.
Good architecture assumes every layer can be wrong for a while. TLS may be valid and still not enough. BGP may be monitored and still briefly diverted. A repository may be reachable and still hostile. Signed packages, signed metadata, short-lived repository metadata, rollback protection, threshold signing, and independent monitoring each close a different door.
There is a counter-argument: smaller vendors can’t build Debian-level repository security overnight. Fair. But at minimum, server-side software that updates with high privileges should verify cryptographic signatures at the client before installation. At this risk level, it’s hard to defend anything less.
The broader cloud security lesson is familiar: infrastructure controls and application controls have to mature together. If you treat them separately, you get exactly this kind of gap, which is why the argument in cloud services and security evolving together applies so neatly here.
FAQ
What is a BGP hijacking attack?
A BGP hijacking attack happens when a network announces IP routes it isn’t authorized to originate, causing other networks to send traffic along the wrong path. More-specific routes, such as a /24 beating a /16, are often preferred by default internet routing rules.
Was every Virtualizor installation compromised?
No. Virtualizor, Softaculous, and BleepingComputer described malicious update delivery to a small number or handful of installations that checked for updates during diverted routing. The vendor also said it couldn’t make a definitive affected-server list because malicious responses came from the attacker’s system.
Why can a valid TLS certificate be dangerous here?
The certificate can be technically valid if the attacker controls the traffic path during domain validation. In that situation, TLS may encrypt a connection to an attacker-controlled server instead of stopping the malicious update.
Does RPKI prevent this kind of attack?
RPKI and Route Origin Validation can reduce bad route propagation, but they aren’t complete by themselves. In this incident, Ars Technica reported that the forged AS path remained RPKI-valid because the ROA allowed prefix lengths from /16 through /24.
What is the first indicator Virtualizor admins should check?
Virtualizor and BleepingComputer both named /etc/systemd/system/java-jre-update.service as an indicator of possible compromise. If you find it, preserve evidence and treat the host as potentially compromised.
EN 
FR 
ES