The BGP hijacking attack used to distribute a malicious Virtualizor update is an unusually important supply-chain incident because it demonstrates that attackers do not necessarily need to compromise a software vendor’s servers, source-code repository or signing infrastructure to corrupt the software update process. Instead, the attackers manipulated internet routing itself. By falsely advertising a more specific route for part of the IP address space hosting Softaculous and Virtualizor services, they were able to redirect traffic intended for legitimate update servers toward infrastructure under their control. Virtualizor installations checking for updates during the affected periods could therefore communicate with an attacker-controlled server while believing they were still connecting to the legitimate vendor.

The incident occurred between approximately 20:57 UTC on August 28 and 06:10 UTC on August 30, 2026. According to Virtualizor’s investigation, AS62390 began announcing the `162.55.80.0/24` network, which belonged to infrastructure hosted by Hetzner and was normally covered by Hetzner’s broader `162.55.0.0/16` route. Because internet routers generally prefer a more specific route, the unauthorized `/24` announcement took precedence over the legitimate `/16` route on networks that accepted it. Traffic destined for Softaculous systems inside that address range was therefore diverted toward infrastructure controlled by the attacker.

This is a fundamental characteristic of Border Gateway Protocol. BGP is effectively the routing system that allows thousands of independent networks to tell one another which IP address ranges they can reach. Historically, much of this system has depended upon networks accepting routing announcements from one another with limited cryptographic verification. If a network incorrectly announces that it can reach an address block belonging to somebody else, other networks may begin sending traffic toward it. The result can be accidental outages, traffic interception or deliberate hijacking.

What makes this incident particularly interesting is that the fraudulent announcement was more specific than the legitimate route. Internet routing normally follows the principle of longest-prefix matching. A `/24` represents a smaller and more specific range than a `/16`, so routers that learned both routes generally preferred the `/24`. The attacker therefore did not need to convince the entire internet that Hetzner’s complete network had moved. They only needed to announce the smaller range containing the relevant Softaculous infrastructure.

Virtualizor’s reconstruction using RIPE routing data indicates that all 368 routing collector peers used in its analysis carried the hijacked route at some stage of the incident. During the active diversion waves, almost every peer carrying a `/24` route selected the attacker-controlled path. This does not mean every byte of internet traffic worldwide was diverted, but it demonstrates that the fraudulent route propagated extensively enough to create a genuine global interception opportunity rather than a local routing anomaly.

The attacker then solved the next problem: TLS. Redirecting traffic alone would normally cause HTTPS clients to detect that the server at the destination cannot present a valid certificate for the legitimate Virtualizor or Softaculous domain. In this case, however, the attacker was able to obtain a technically valid certificate from Let’s Encrypt covering multiple Softaculous and Virtualizor domains. The certificate authority’s automated domain-control validation requests were themselves affected by the BGP hijack, allowing the attacker-controlled server to appear to demonstrate control of the legitimate domains.

This is one of the most important aspects of the incident because it demonstrates what TLS does and does not guarantee. HTTPS protects the connection between a client and the server authenticated by the certificate presented during the connection. It does not independently prove that internet routing delivered the client to the infrastructure the domain owner originally intended. If routing is successfully hijacked and the attacker can also satisfy certificate-authority validation, the victim can establish a perfectly encrypted TLS session with the attacker.

There may therefore be no certificate warning, browser error or obviously invalid HTTPS connection. Encryption can function exactly as designed while the endpoint identity has been subverted through another layer of infrastructure. Security controls frequently fail not because one cryptographic primitive is broken, but because attackers find a way to undermine the assumptions surrounding it.

The attackers reportedly obtained a certificate covering domains including `virtualizor.com`, `api.virtualizor.com`, `files.virtualizor.com`, `softaculous.com` and several other related product domains. This expanded the potential interception surface beyond a single update URL. The affected IP range also hosted the Softaculous client and billing area, meaning users connecting to those services during the hijack window may also have communicated with attacker-controlled infrastructure.

The most serious confirmed consequence was delivery of a malicious Virtualizor update package. Virtualizor says a small number of installations that checked for software updates while their traffic was diverted received the malicious package. The vendor describes this as affecting only a handful of servers rather than the wider Virtualizor customer population, but it cannot produce a definitive list because those update requests went to the attacker’s server and therefore never appeared in Virtualizor’s own logs.

This creates an important incident-response problem. Normally, a software vendor investigating malicious updates can examine server logs to identify which customers downloaded the affected file. In a BGP hijacking scenario, the malicious traffic never reaches the legitimate update infrastructure. From the vendor’s perspective, the affected clients simply disappear from normal telemetry during the interception period. That is why Virtualizor has advised every operator to perform compromise checks rather than notifying only a known list of victims.

The incident becomes significantly more serious because Virtualizor’s update clients did not cryptographically verify the packages they downloaded. HTTPS provided transport protection, but there was no independent package signature allowing the client to determine whether the update itself had actually been produced by Virtualizor. Once the attacker successfully controlled both the network route and TLS endpoint, the malicious package could therefore be accepted as though it were a normal update.

This exposes an important distinction between transport security and artifact security. HTTPS protects software while it travels across the network. Code signing protects the software itself. A secure update architecture should ideally use both because they defend against different failures. Even if DNS, BGP, a CDN, proxy or TLS endpoint is compromised, a client that independently verifies the vendor’s digital signature on the downloaded package can reject unauthorized code.

In this incident, cryptographic package signing would have created exactly that additional boundary. The attacker could still have redirected the update request and returned a malicious file, but unless they also possessed the vendor’s signing key, the Virtualizor client could have refused to install it. The BGP hijack would then primarily have caused denial of service or update failures rather than silent execution of attacker-controlled software.

Virtualizor has now stated that it plans to implement code-signing mechanisms for all packages. This is arguably the most important long-term remediation arising from the incident. Network routing should not need to be perfectly trustworthy for a software update mechanism to remain secure. Update clients should assume that the delivery path can eventually be compromised and independently establish whether the package came from the legitimate publisher.

The known indicator associated with the malicious update is a systemd service located at `/etc/systemd/system/java-jre-update.service`, together with a corresponding enabled or running `java-jre-update` service. The naming is unsurprising because attackers frequently choose filenames that resemble legitimate system components or common software updates. A service named like a Java runtime update is considerably less likely to attract immediate administrator attention than something helpfully labelled `attacker-backdoor.service`.

Virtualizor specifically warns administrators who discover this service not simply to delete it immediately. Its presence should be treated as evidence that the server received the malicious update and therefore experienced a broader compromise. Removing one systemd unit does not answer what commands were executed, what credentials were stolen, what additional persistence was created or which systems the attacker subsequently accessed.

Affected servers should therefore undergo proper compromise assessment. Administrators should review SSH authorized keys, local user accounts, scheduled tasks, cron jobs, systemd services, modified binaries and unusual outbound network connections. API credentials associated with Virtualizor should be rotated, unknown API keys removed and access restricted to trusted source addresses wherever practical.

Because Virtualizor is a VPS management platform, server compromise can have unusually large consequences. A compromised Virtualizor host may control numerous virtual machines belonging to customers. Attackers gaining administrative access to the virtualization management layer may therefore have opportunities to manipulate, stop or inspect multiple hosted systems rather than compromising one ordinary server.

This is why management-plane security deserves particularly strong protection. Virtualization control panels, hypervisor managers, backup systems and orchestration platforms sit above the workloads they manage. Compromise of one application server may expose one application. Compromise of the infrastructure controlling dozens or hundreds of virtual machines can expose an entire hosting environment.

Administrators who discover the known malicious service should consequently investigate whether the attacker accessed or modified guest virtual machines, templates, storage or networking configuration. Virtualizor API keys may provide another persistence path and should not be overlooked merely because the malicious systemd service has been removed.

SSH access requires particular attention. Attackers with root-level access commonly install their own public keys into authorized-key files because this creates stable access independent of passwords. Password rotation will not remove an unauthorized SSH key. Administrators need to examine root and administrative-user authorized keys directly and compare them with known legitimate keys.

Scheduled tasks and cron entries provide another common persistence mechanism. The malicious update may have installed the visible systemd service while later attacker activity created additional mechanisms. Incident responders should therefore search for recently created or modified persistence across the operating system rather than limiting the investigation to Virtualizor-specific files.

Outbound traffic history can reveal command-and-control activity or secondary payload downloads. A virtualization host suddenly communicating with unfamiliar internet destinations after an update should receive immediate scrutiny. Servers managing VPS infrastructure generally have reasonably predictable communication patterns, making new external destinations potentially useful indicators.

Centralized logging becomes particularly valuable because root-level attackers may alter logs on the compromised host. Authentication events, firewall data and management activity should ideally be forwarded to infrastructure the Virtualizor server cannot modify. If all forensic evidence remains only on the system controlled by the attacker, confidence in that evidence necessarily decreases.

Where substantial evidence of compromise exists, rebuilding the management server from a known-good image may provide stronger assurance than attempting to remove malicious artifacts individually. Root access means attackers can theoretically alter deep system components, making complete verification of an in-place cleanup difficult.

Credential rotation should extend beyond Virtualizor where appropriate. If the compromised host contained cloud credentials, backup passwords, database credentials, SSH private keys or customer-management secrets, those should be evaluated as potentially exposed. The real blast radius of server compromise is determined largely by the trust the server possessed before it was attacked.

The incident also affected Softaculous’s client and billing area. The vendor advises users who logged into the client area between approximately 20:57 UTC on August 28 and 06:10 UTC on August 30 to reset their client-area passwords, review account activity and monitor relevant payment-card statements if they entered payment information during the window. Softaculous says card processing itself takes place through external payment gateways, but information entered through an attacker-controlled page could still theoretically have been observed before submission.

Session invalidation is equally important. Softaculous says it is invalidating client-area sessions associated with the affected period. This is necessary because resetting a password does not always invalidate an already authenticated session token. Attackers who captured a valid session during the hijack might otherwise retain access after the user changed credentials.

API keys associated with Softaculous accounts should also be regenerated. API credentials are often more dangerous than passwords because they may be long lived, may not use MFA and are designed for automated access. If a client session or account was intercepted, attackers could potentially obtain keys that continue working after password changes.

The BGP aspect of the incident deserves broader attention because it exposes a weakness largely invisible to conventional enterprise security controls. Firewalls, endpoint security and application authentication can all work correctly while traffic is being sent to the wrong network. Enterprises generally have little direct control over global BGP route propagation between internet service providers.

Technologies such as Resource Public Key Infrastructure, route-origin validation and careful BGP filtering are intended to reduce unauthorized route announcements. RPKI allows address-space owners to cryptographically specify which autonomous systems are authorized to originate routes for their prefixes. Networks performing Route Origin Validation can reject announcements whose origins conflict with those authorizations.

However, routing security remains an ecosystem problem. Protection depends not only on whether the organization publishes appropriate routing authorization information but whether upstream and transit networks validate routes correctly. A weak participant can sometimes propagate a route that influences large portions of the internet.

The Virtualizor incident is also a reminder that more-specific route attacks deserve close attention. Even when a legitimate organization announces a broad prefix correctly, an attacker can attempt to advertise a narrower range. Networks following longest-prefix routing may prefer that smaller route unless appropriate filters or routing validation prevent it.

Organizations operating critical update infrastructure should therefore monitor their own prefixes continuously. External BGP-monitoring services can detect unexpected route origin changes, new more-specific announcements and unusual AS paths. Routing anomalies need an emergency escalation path just like unauthorized DNS or certificate issuance.

Certificate Transparency monitoring provides another useful layer. Because publicly trusted TLS certificates are logged into Certificate Transparency systems, organizations can monitor for certificates issued for their domains that they did not request. In this case, detection of an unexpected certificate covering Virtualizor and Softaculous domains could have provided another indication that domain-validation traffic or infrastructure had been compromised.

However, certificate monitoring is primarily detective rather than preventive. Once a valid certificate has already been issued, attackers may be able to use it until revocation or expiry. Certificate Authority Authorization DNS records can restrict which CAs are permitted to issue certificates for a domain, though that control alone does not prevent an attacker from abusing the authorized CA if domain validation itself is redirected.

This demonstrates why security systems should avoid relying on one externally controlled proof of identity. Software update security can combine HTTPS, certificate monitoring and package signatures. Routing infrastructure can combine RPKI and BGP monitoring. Account security can combine passwords, MFA and session controls. Every additional independent verification mechanism makes it harder for compromise of one infrastructure layer to defeat the entire system.

The attack is particularly interesting as a software supply-chain incident because the vendor’s software repository itself was not necessarily compromised in the traditional sense. The attacker inserted themselves into the distribution path. From the customer's perspective, however, the outcome was effectively identical: the trusted update mechanism delivered attacker-controlled software.

This broadens how organizations should think about supply-chain security. Supply-chain attacks do not require malicious source code to enter the vendor’s Git repository. Attackers can compromise build systems, package repositories, CDN infrastructure, DNS, cloud accounts, certificates or network routing. Anything involved between software creation and execution on the customer's machine forms part of the supply chain.

End-to-end package signatures are powerful because they survive many of these intermediary failures. The vendor signs the artifact after building it, and the customer verifies that signature immediately before installation. Mirrors, networks and CDNs can distribute the file without needing to be fully trusted for authenticity.

The signing private key then becomes an extremely high-value asset and must itself receive strong protection. Hardware Security Modules, offline or tightly controlled signing services and audited release workflows can reduce the risk that attackers compromise the signing key and simply produce malicious packages carrying valid signatures.

Key rotation and revocation procedures should also exist before an incident. If a signing key is compromised, vendors need a reliable way to tell clients which key should no longer be trusted and introduce a replacement securely. Update security therefore requires an entire key-management lifecycle rather than simply adding a signature field to a package.

Transparency logs for software releases could provide an additional future safeguard. Signed package hashes published into append-only transparency systems would allow customers and researchers to verify that the update they received corresponds to a publicly recorded vendor release. An attacker who intercepts one customer’s update traffic would then have difficulty presenting a unique malicious build without creating an observable discrepancy.

The Virtualizor incident also demonstrates how auto-update mechanisms create both security benefits and supply-chain risk. Automatic updates are generally desirable because they allow vendors to distribute vulnerability patches quickly. But the same automation gives the update channel enormous privilege. Once compromised, it can distribute malicious code directly into large numbers of trusted servers without user intervention.

Automatic update systems should therefore be among the most strongly authenticated pathways in any software product. The ability to execute a software update is effectively remote code execution by design, except the remote party is supposed to be the trusted vendor.

That trust needs cryptographic enforcement rather than assumption.

The incident window lasted approximately 33 hours and occurred in two major diversion waves. Virtualizor reports that the first wave began late on August 28 and was substantially mitigated after Hetzner began directly announcing the affected `/24` around 08:50 UTC on August 29. After an approximately eleven-hour lull, the unauthorized announcement returned for another prolonged wave before normal routing was restored around 06:10 UTC on August 30.

The existence of multiple waves is operationally significant because temporary disappearance of a malicious route does not necessarily mean the incident is over. Routing attacks can flap, be withdrawn and return. Network teams should continue monitoring after apparent recovery rather than assuming one corrective announcement permanently resolved the problem.

Virtualizor also states that Hetzner did not proactively notify it about the routing hijack and that mitigation occurred only after escalation. Regardless of the eventual attribution of operational responsibility, the episode demonstrates why organizations should independently monitor infrastructure critical to their own security. Relying entirely on an upstream provider to notice and communicate every routing anomaly creates another dependency in the detection chain.

The vendor’s September 1 release of Virtualizor 3.2.9.9 adds a Security Analyzer to the administrative interface. This can help operators inspect their environments for known indicators associated with the incident, although security teams should remember that a post-incident scanner cannot prove absence of compromise. Attackers may remove known artifacts or create additional persistence not covered by the tool.

The known `java-jre-update.service` indicator is therefore useful for identifying confirmed compromise but should not be interpreted in reverse. Finding the file strongly indicates that the malicious package was installed. Not finding it does not mathematically prove the server was never affected, particularly if attackers had root access and could remove evidence.

Organizations should combine the vendor scanner with host, network and identity investigation. Recent outbound connections, changed SSH keys, new accounts and unusual API activity may reveal compromise even when the original malicious service is absent.

The fact that only a small number of systems are currently known to have received the malicious package should also be interpreted carefully. Virtualizor explicitly explains that it cannot create a definitive victim list because intercepted requests did not reach its logging infrastructure. This is not evidence that the attack was widespread across all Virtualizor customers, but neither is the absence of vendor logs evidence that a particular server was safe.

Administrators should therefore determine whether their servers could have performed an update check during the affected routing window and examine them accordingly.

The broader architectural lesson is that software trust needs to survive network compromise. The internet routing system, DNS, TLS certificate ecosystem and CDN infrastructure are extraordinarily useful but none should represent the sole proof that executable code is authentic.

A secure update client should ultimately ask a very simple question before installing an update: was this package signed by a key that I already trust?

If the answer is no, the update should fail.

That would have substantially changed the outcome of this incident. The attacker could have hijacked BGP, redirected traffic, obtained a valid TLS certificate and impersonated the update endpoint successfully, yet the malicious Virtualizor package would still have lacked the vendor's cryptographic signature.

The attack would have broken availability.

It would not automatically have broken integrity.

That separation is one of the core principles of defense in depth.

The incident also exposes why enterprises should verify important software updates independently where possible. Infrastructure teams often allow servers to download updates automatically over HTTPS and assume the vendor’s domain and certificate provide sufficient assurance. For high-privilege software such as hypervisor managers, security appliances and orchestration systems, organizations should increasingly expect signed artifacts, published checksums and verifiable release metadata.

Vendors should make those mechanisms simple enough that customers actually use them. Security that requires administrators to manually copy hashes from a webpage for every routine update will eventually be bypassed for operational convenience. Verification belongs inside the update client itself.

For Virtualizor operators, the immediate priorities are therefore clear. Systems should be upgraded to the vendor’s latest security release, including the 3.2.9.9 update containing the new analyzer. Every server should be checked for `/etc/systemd/system/java-jre-update.service` and the associated service. Virtualizor API credentials should be regenerated and restricted to trusted IP addresses. Administrators should audit SSH keys, local users, scheduled tasks, cron jobs and unusual network activity, and any server showing indicators of compromise should be treated as a potentially root-compromised virtualization-management host rather than merely as a system containing one malicious file.

Users who interacted with the Softaculous client portal during the affected period should change passwords, avoid reused credentials, review account activity and regenerate relevant API keys. Where payment details were entered during the hijack window, transaction and card activity should be monitored according to the vendor’s guidance.

The wider lesson is even more important than the immediate remediation. The attacker did not need to discover a zero-day in Virtualizor, compromise Softaculous’s production servers or steal a certificate private key. They attacked assumptions shared between several layers of internet infrastructure.

BGP assumed that the more specific route was legitimate.

The certificate authority’s validation process assumed that traffic reached the true domain owner.

TLS correctly encrypted communication with the holder of the newly issued certificate.

The Virtualizor updater assumed that a package delivered through that authenticated HTTPS connection was genuine.

Each component behaved largely according to its own rules.

The security failure emerged because those rules were chained together.

This is precisely why modern security architecture cannot rely on transitive trust. The software updater should not trust a package solely because HTTPS trusted the server. HTTPS should not be considered sufficient proof that routing was correct. Applications should independently verify the properties that matter to them.

For an update system, that property is software provenance and integrity.

The Virtualizor BGP hijacking incident is therefore more than a networking story and more than a malicious-update story. It is a textbook example of how attackers can move sideways across infrastructure layers until they reach the weakest missing control.

The internet route was hijacked. TLS was successfully impersonated with a valid certificate. The malicious package reached the customer. And because the final artifact itself was not cryptographically signed, the customer had no independent way to distinguish the attacker’s update from the vendor’s. That is the security lesson worth remembering. Never make the transport path the final authority over whether executable software can be trusted.

Hackers delivered malicious updates to the Virtualizor VPS management software after hijacking BGP routing for its update infrastructure and redirecting update requests to malicious servers. [...]

Source: Hackers push malicious Virtualizor update in BGP hijacking attack via Bleeping Computer — published 01 Sep 2026.