A 33-hour BGP hijack delivered a malicious Virtualizor update and persistent root access

August 28, 2026, 20:57 UTC. An unrelated network begins announcing a block of Hetzner IP addresses used by Softaculous. August 29. The vendor alerts Hetzner, then a second wave resumes that evening. August 30, 06:10 UTC. The rogue route is withdrawn. Why it matters: for 33 hours, the update traffic of the Virtualizor control panel flowed through an attacker-controlled server, which delivered a malicious package and gained persistent root access on at least five of thirty-four hypervisors inspected.

A routing hijack that became a supply-chain compromise

The starting point is a mechanism the routing community has known about for years: BGP route selection. A malicious announcer published a more specific prefix than the one Hetzner normally advertises for Softaculous’s ranges. Under standard BGP route selection, the more specific route wins wherever it is accepted. The result: some traffic destined for the vendor was redirected to an attacker-controlled server, with no infrastructure compromise required at all.

The systems affected are not trivial. The hijack hit the Virtualizor update endpoint, plus Softaculous’s client site and billing site. The attacker even obtained a valid TLS certificate from Let’s Encrypt, because the certificate authority’s automated domain-ownership validation was routed through the hijack too. Redirected connections therefore triggered no certificate warnings — the one signal that should have alerted an administrator was neutralized.

An unsigned package, then persistent root

The most serious part is not the hijack itself but what it enabled. Softaculous confirmed that a malicious Virtualizor update was delivered to “a handful” of installations whose update checks passed through the attacker’s server. The reason is technical and fits in a single sentence: “our product update clients did not yet cryptographically verify update packages, so a modified package would not have been rejected on that basis.”

The consequences are measurable. According to The Hacker News, one provider found root compromise on five of the thirty-four hypervisors it checked. The indicator of compromise published by the vendor is a systemd unit: /etc/systemd/system/java-jre-update.service. Softaculous advises operators not to delete it immediately, but to contact the vendor so evidence can be preserved.

A 72% probability window of exposure

The scale of the hijack can be quantified. During each wave, Softaculous estimates that a given server had roughly a 72% chance of sitting on a network that routed the affected range through the attacker. The figure is based on the proportion of RIPE routing collector peers carrying the hijacked route, not the volume of traffic actually intercepted — it measures potential exposure, not the number of confirmed victims.

The timeline also shows an attack that “flapped” like an intermittent signal. The route was initially accepted by “essentially every internet vantage point that receives it,” then flapped repeatedly. After the vendor alerted Hetzner around 08:50 UTC on August 29, the hosting provider began announcing the same more-specific range directly, cutting the diversion to almost zero for 11 hours. The second wave returned around 20:00 UTC for about 10 hours, before the route was withdrawn between 05:50 and 06:10 UTC on August 30.

Why BGP stays an open door

This is not a one-off accident: it belongs to a family of attacks that persists because the internet’s control plane still runs largely on trust. The more-specific prefix trick exploits a trade-off as old as the protocol itself — the more precise route wins, without the accepting network verifying that the announcer is legitimate.

The fix does exist: Route Origin Validation (ROV) backed by the RPKI infrastructure. By publishing ROAs (Route Origin Authorizations), a prefix holder cryptographically declares which AS is allowed to announce it; a router applying ROV then rejects unauthorized announcements. The problem is adoption: ROV coverage remains partial worldwide, and a rogue route needs only one unfiltered path to propagate. The Softaculous attack leaned on exactly that asymmetry.

Beyond origin validation, the next layer — ASPA (Autonomous System Provider Authorization) — addresses a harder problem: verifying not just who may originate a prefix, but which paths are legitimate. ROV answers the first question; ASPA, still maturing in deployment, answers the second and would blunt the path-forgery variants that pure origin filtering cannot catch. Initiatives like MANRS (Mutually Agreed Norms for Routing Security) exist to turn these practices from checkbox items into baseline hygiene for network operators.

The broader context shows the pressure is not easing. On September 12, 2026, the BGP.Exchange site — a virtual internet exchange platform — was compromised and defaced, a reminder that routing operators themselves are targets. Days earlier, a multi-day BGP incident had already knocked out the national control plane in Laos. Route hijacks are no longer academic curiosities: they have become an operational attack tool.

What a control-panel operator should do

The incident combines two structural weaknesses most hosting providers still share. The first is routing, the second is the update chain. Both are fixable.

• Turn on RPKI ROV at your upstream. The more-specific prefix would not have been accepted by most peers if Route Origin Validation had been active. Publish ROAs for your own prefixes, and require your transit provider to apply ROV to the routes it receives.
• Sign your update packages. Client-side cryptographic verification — an Ed25519 signature, a signed manifest — would have rejected the modified package regardless of routing. It is the only defense that survives a successful hijack.
• Rotate secrets inside the exposure window. Client-area passwords, Virtualizor API keys, unknown SSH keys, added accounts, scheduled tasks, and abnormal outbound connections: everything must be reset on servers that were active during the window.
• Treat java-jre-update.service as evidence, not as a file to purge. Its presence confirms compromise; deleting it before analysis destroys the timestamp and provenance of the artifact.

Softaculous has invalidated client-area sessions created during the incident and continues investigating its other products — Backuply, SitePad, Webuzo — without having identified a malicious package so far.

The lesson beyond BGP

Strip away the routing and this is a familiar failure class: a compromised build pipeline or a poisoned package registry, where trust in the transport quietly became trust in the artifact. The attacker did not have to break Softaculous’s code or Hetzner’s network — it only had to sit in the path and serve a convincing substitute. Signing updates closes that loop no matter how the bytes arrive, which is why it belongs in the same severity class as the routing fix itself: both are cheap, both are overdue, and both would have stopped this attack at a different layer.

Verdict

This hijack is the cleanest demonstration in years that a network-layer problem can turn into a supply-chain compromise without exploiting a single software vulnerability. If you run Virtualizor or an equivalent panel, look for java-jre-update.service before anything else, then rotate secrets and demand signed updates from your vendor. If you are a transit provider or upstream host, enable RPKI ROV on your peering sessions: it is the only link that would have cut the attack off at the root. If you manage an estate that verifies its updates without signatures, treat every update crossing the public internet as an open vector — the next hijack will not wait 33 hours to deliver its payload.

References

• The Register — 33-hour BGP hijack of Softaculous traffic prompts security scramble, September 1, 2026
• The Hacker News — BGP Hijack Delivers Malicious Virtualizor Update That Establishes Persistent Root Access, September 2, 2026
• Virtualizor — Security Incident: BGP Hijacking
• Born City — BGP.Exchange Website Compromised, September 12, 2026
• ETTAYEB — Laos: four days of BGP outage on a national control plane