A BGP hijacking attack can poison software updates when attackers reroute an update server’s IP traffic, obtain believable TLS coverage, and serve a modified package to clients that don’t verify signed artifacts. The August 2026 Virtualizor incident showed the chain clearly: routing control first, certificate validation second, update compromise third. HTTPS helped less than many teams assume. Package signing, RPKI, pinned trust, and sane update architecture are the real safety net.
What happened in the Virtualizor case
On August 31, 2026, Virtualizor published a “Security Incident – BGP Hijacking” advisory after traffic for 162.55.80.0/24 had been diverted away from Softaculous infrastructure. Softaculous later said the affected addresses included update endpoints and the client or billing site, with the Virtualizor update system affected.
The timing matters. Virtualizor said the first unauthorized announcement for 162.55.80.0/24 was observed at 20:57:30 UTC on August 28, 2026, and The Hacker News said it confirmed that timing using RIPE Stat data. The wider incident window ran until August 30 at 06:10 UTC, with two active hijack periods rather than one clean outage.
The hijacked prefix was part of Softaculous infrastructure hosted at Hetzner and normally covered by Hetzner’s broader 162.55.0.0/16 route. In BGP, a more specific route often wins, so an unauthorized /24 can attract traffic even while the legitimate /16 still exists. Small prefix. Large blast radius.
Virtualizor and Softaculous identified AS62390/NexonHost as announcing the prefix via AS6204/Zet.net, while AS24940/Hetzner remained the apparent origin in the AS path. That detail is uncomfortable because it shows why routing incidents can look superficially legitimate to downstream networks that aren’t validating origin authorization.
Why a BGP hijacking attack can beat HTTPS
A common mistake is to treat HTTPS as the update system. It isn’t. HTTPS protects a connection to whoever can satisfy certificate validation for the name you requested, but if routing is hijacked and domain validation flows through the attacker’s path, the attacker may be able to obtain a technically valid certificate.
Virtualizor said the attacker obtained a valid Let’s Encrypt certificate for affected domains during the hijack because domain-validation traffic also routed through attacker-controlled infrastructure. Reported affected names included virtualizor.com, api.virtualizor.com, files.virtualizor.com, softaculous.com, files.softaculous.com, webuzo.com, sitepad.com, backuply.com, and others.
Ars Technica reported on September 2, 2026, that Let’s Encrypt said CAA account binding would have made issuance significantly more difficult for the attacker. That’s a useful edge case: CAA alone tells certificate authorities who may issue, but account binding narrows the path further by tying issuance to a specific CA account.
Here’s the practical point. If your updater accepts any package delivered over a TLS session, a BGP hijacking attack turns your routing table into part of your supply chain. Honestly, that’s a fragile design for anything that runs as root.
The update-chain failure, not just the routing failure
Virtualizor said a malicious update package was delivered to a small number, or handful, of installations that checked for updates while traffic was diverted. The company also said its update clients did not yet cryptographically verify update packages, so a modified package would not have been rejected on that basis.
That missing verification is the hinge of the incident. A signed package scheme would not make route hijacking harmless, but it changes the attacker’s problem from “serve a malicious file” to “produce a signature trusted by the client.” Those are very different levels of difficulty.
The same lesson appears again and again in enterprise incidents: patching is necessary, but trust verification has to travel with the patch. If you track vulnerability-driven breaches, the shift covered in Verizon DBIR 2026 vulnerability trends is a useful backdrop for why update systems themselves now deserve threat modeling, not just uptime monitoring.
The Hacker News reported on September 2, 2026, that a hosting-provider account, AlbaHost on LowEndTalk, said 5 of 34 checked Virtualizor hypervisors had malicious modifications. Treat that as single-source reporting, not a verified global infection rate. Still, the math is sobering: 5 divided by 34 is about 14.7%, which is far too high if your own fleet happened to update in the wrong window.
Timeline and numbers that matter
The incident wasn’t just a momentary route leak. Based on the reported windows, the first active hijack ran from about 20:57 UTC on August 28 to 08:50 UTC on August 29, 2026. That is roughly 11 hours and 53 minutes of exposure.
A second active period ran from about 20:57 UTC on August 29 to 06:10 UTC on August 30, 2026. That adds around 9 hours and 13 minutes. Combined, the two active periods total roughly 21 hours and 6 minutes, spread across a 33-hour incident envelope from the first observed announcement to the final reported end.
| Event | Reported time in 2026 | Security significance |
|---|---|---|
First unauthorized announcement for 162.55.80.0/24 |
August 28, 20:57:30 UTC | Traffic could begin moving toward attacker-controlled infrastructure |
| First active hijack period ends | August 29, about 08:50 UTC | About 11 hours 53 minutes of exposure |
| Second active hijack period begins | August 29, about 20:57 UTC | Risk resumes after a gap |
| Second active hijack period ends | August 30, about 06:10 UTC | About 9 hours 13 minutes of additional exposure |
| Virtualizor advisory published | August 31 | Administrators get official IoC and mitigation guidance |
| Virtualizor 3.2.9 Patch 9 / 3.2.9.9 released | September 1 | Security Analyzer added to the admin panel |
Ars Technica reported that Hetzner reclaimed the address space about 12 hours after the first hijack began, stopped announcing the more specific path, and then reacted almost 10 hours after the second hijack began. That reporting underlines a painful operational reality: route hijacks are sometimes noticed and fought in phases, while update clients keep doing their scheduled work.
How to check exposure after a poisoned update
Virtualizor’s known indicator of compromise is direct and worth checking first: /etc/systemd/system/java-jre-update.service, plus a corresponding enabled or running java-jre-update service. Don’t stop at the admin panel if you suspect exposure; inspect the host.
The Hacker News also reported alleged artifacts on September 2, 2026, including payload SHA-256 b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7, files /usr/lib/jvm/.cache/jre-runtime.dat and /tmp/widdow.jar, and C2 domains cdn[.]nerat[.]cc and connect[.]ne-rat[.]xyz. Those details were reported by one outlet, so use them as hunting leads rather than the only source of truth.
- Check whether Virtualizor hosts requested updates during the August 28-30, 2026 exposure windows.
- Look for
java-jre-update.serviceunder systemd and verify whether the service is enabled, running, or recently created. - Review package files, shell history, cron entries, systemd timers, and outbound DNS or proxy logs around the same window.
- Install Virtualizor 3.2.9 Patch 9 / advisory-named 3.2.9.9 and run the Security Analyzer added on September 1, 2026.
- If compromise is suspected, rebuild from trusted media rather than merely deleting the visible service.
Detection teams should also correlate route-change timing with host telemetry. A SIEM can help if it has package-manager logs, systemd events, DNS, and egress flows in the same place; the detection patterns described in modern SIEM threat detection are directly relevant here.
For larger hosting environments, don’t assume the quiet servers are clean. Hypervisors often run different update schedules, and maintenance automation can hide the only timestamp you needed. If you operate dedicated infrastructure, the operational planning mindset in dedicated server deployment applies well to recovery: inventory first, isolation second, rebuild decisions third.
Defenses that actually reduce the risk
No single control fixes this class of incident. RPKI-based Route Origin Validation, described by NIST as a way to mitigate some BGP route hijacking and misconfiguration risks, helps networks reject invalid origin announcements. It doesn’t verify your software package.
Package signing addresses a different layer. Sigstore documents signing and verification for release files, binaries, SBOMs, and container images, with signing events recorded in a tamper-resistant public log. The Update Framework goes further for update systems by specifying signed metadata, versioning, expiration, threshold signatures, and defenses against rollback, freeze, and mix-and-match attacks.
Virtualizor said it reported the fraudulent certificate to Let’s Encrypt for revocation, reported the incident to network operators and CERTs, and plans code signing for all packages. That plan is the right direction, although The Hacker News reported that as of September 2, 2026, Virtualizor had not published a malicious-package filename or hash, affected update-channel list, or build enforcing package signing.
Zero trust is an overused phrase, but the concept is sharp in software updates: don’t trust the network just because it presents the expected name. The approach explained in trust verification for modern cybersecurity maps neatly to update clients, where every artifact should prove itself before installation.
Red-team exercises should include routing and repository failure modes, not just phishing and exposed admin panels. If your simulations already cover adversary automation, autonomous red teaming can be a useful way to test whether monitoring catches unusual update behavior after the initial access path.
Why repository architecture matters more than people think
A hardened updater should assume the download server can lie. That sounds harsh. It’s also the only assumption that survives a BGP hijacking attack, CDN compromise, stale mirror, misissued certificate, or DNS control failure.
Good repository design separates transport security from artifact trust. TLS protects confidentiality and makes casual tampering harder, while signed metadata tells the client which version is valid, when metadata expires, and which keys are authorized to approve a release. Threshold signatures can prevent one stolen signing key from shipping a poisoned build alone.
There’s also a boring pitfall nobody likes to fund: key rotation and offline root keys. If all signing keys sit on the same internet-facing build host that publishes packages, the signature becomes a decorative stamp. At that point, attackers don’t need to beat the updater; they just need to steal the pen.
Cloud providers, hosting companies, and software vendors share this problem. The broader argument in cloud services and security evolving together fits the Virtualizor case well because routing, certificate issuance, and update delivery crossed organizational boundaries.
FAQ
What is a BGP hijacking attack?
A BGP hijacking attack happens when a network announces IP routes it shouldn’t, causing other networks to send traffic to the wrong place. Attackers can use that position to intercept, drop, or modify traffic depending on the protocol and the victim’s defenses.
Can HTTPS stop malicious software updates?
HTTPS helps, but it can’t be the only control. If attackers can redirect validation and obtain a valid certificate, an update client still needs cryptographic package verification before installing anything.
Was only Virtualizor affected in the 2026 Softaculous incident?
Softaculous said the Virtualizor update system was affected and that it had found no evidence of compromise for other products as of its August 31, 2026 update. Administrators should still follow vendor guidance for any systems that contacted affected domains during the hijack window.
What is the first IoC admins should check?
Virtualizor named /etc/systemd/system/java-jre-update.service and a corresponding enabled or running java-jre-update service as the known indicator of compromise. Check it before assuming a host missed the poisoned update window.
Does RPKI prevent all BGP hijacking?
No. NIST describes RPKI-based Route Origin Validation as a mitigation for some BGP hijacking and misconfiguration risks, especially invalid origin announcements. It’s valuable, but software update signing and client-side verification still remain necessary.
EN 
FR 
ES