BGP Hijack Delivered a Backdoored Virtualizor Update

The update came from the right domain over valid TLS. The route to the vendor had been stolen, so the traffic reached an attacker-controlled server instead.

What Happened?

Between 28 and 30 August 2026, attackers announced a BGP route they had no authority over, pulling Softaculous update traffic to a server they controlled. Any Virtualizor installation that checked for updates during one of the diverted routing intervals could have received the backdoored package.

AlbaHost, a hosting provider, reported finding the malicious modifications on 5 of its 34 Virtualizor hypervisor nodes. Virtualizor described the impact as a handful of servers and shipped Patch 9 with a scanning tool. (LowEndTalk, The Hacker News)

What Is BGP Hijacking?

BGP is how networks tell each other which IP ranges they can reach. It runs largely on trust: announce a route, and others generally believe you.

Here the attacker, AS62390, announced 162.55.80.0/24 — a more specific slice of Hetzner's legitimate 162.55.0.0/16. Routers prefer the most specific match, so the narrower announcement won. Upstream AS6204 accepted and propagated it. (BGPKIT)

The hijack ran in two waves totalling roughly 22 hours inside a 33-hour window. (BGPKIT)

What About RPKI?

The forged AS path retained Hetzner's AS24940 as the apparent origin. BGP researchers Doug Madory and Ben Cartwright-Cox reported that Hetzner's ROA allowed /24 announcements, which would make the forged-origin route RPKI-valid. However, a separate post-incident validation reported a maxLength of /16. Without a point-in-time ROA snapshot from the attack window, the exact RPKI status should be presented as disputed rather than settled. (Ars Technica)

RPKI Route Origin Validation checks whether the apparent origin AS is authorised to announce the prefix and whether the announcement respects the ROA's permitted prefix length. It does not cryptographically prove that the entire AS path is genuine.

Stronger path-validation mechanisms such as ASPA and BGPsec can address additional classes of routing manipulation, but deployment remains limited and uneven. (APNIC)

What Did the Backdoor Do?

On AlbaHost's affected systems, malicious commands had been inserted into three legitimate Virtualizor files, which then:

• Added an attacker-controlled SSH key to the root account
• Installed a Java 17 runtime and ran a Java payload as root
• Persisted through a systemd unit named java-jre-update.service
• Created an account called proxyuser

Observed infrastructure and indicators included cdn[.]nerat[.]cc, connect[.]ne-rat[.]xyz, and a Java connection to 31.77.220[.]138:2025. (LowEndTalk)

What Should You Do Now?

If you run Virtualizor:

• Run the vendor's Patch 9 scanner
• Check for /etc/systemd/system/java-jre-update.service and /tmp/widdow.jar
• Look for a proxyuser account and unexpected keys in root's authorized_keys
• Review outbound connections to the domains and address above
• Rotate API keys and restrict them to trusted addresses
• If java-jre-update.service is present, preserve evidence and contact Virtualizor support before deleting it

Why Does It Matter?

The trust chain broke below the layer anyone was watching. Domain correct, certificate valid, vendor genuine — and the packets went somewhere else. Cryptographic package-signature verification would have provided an independent trust check even after routing and TLS validation were defeated.

Common Mistakes

• Treating RPKI as solved routing security. It validates the origin and prefix length, not the whole AS path.
• Trusting TLS alone to prove the real server. In this incident, the BGP hijack also diverted the CA's automated domain-validation traffic, allowing the attacker to obtain a valid Let's Encrypt certificate.
• Assuming vendor update clients independently verify downloaded packages. Virtualizor confirmed that its update client did not yet cryptographically verify update packages.
• Leaving hypervisors out of scope. Root on the host can give an attacker powerful access to, or control over, the guests it runs.

How to Reduce the Risk

• Publish ROAs for your own prefixes, and monitor for unexpected announcements covering them
• Alert on new systemd units, new local accounts, and changes to root's authorized_keys
• Verify every update with a cryptographic signature anchored to a vendor signing key distributed independently of the download channel
• Constrain outbound traffic from hypervisors, so unknown destinations fail

What Should Security Testing Cover?

Ask your testers to establish:

• Whether your software update paths verify signatures, or only TLS
• Whether a new root SSH key or systemd service raises an alert anyone acts on

How OraSec Can Help

Update integrity and management-plane exposure sit outside most testing scopes, which is where this attack landed. OraSec's network infrastructure penetration testing examines what your management systems trust, and what they can reach.

Conclusion

Nobody was phished. No known Virtualizor software vulnerability was required to deliver the malicious update. The attacker changed which server the internet believed was the vendor's, for 22 hours, and that was enough.

FAQs

Would RPKI have prevented this? Reports disagree. The forged path kept the legitimate origin ASN, and whether the announcement was RPKI-valid depends on Hetzner's ROA prefix length at the time, which is disputed.

How do I know if I was affected? Run the vendor scanner and check for the systemd unit, the proxyuser account, and unexpected root SSH keys.

Is patching enough? Only if the host was never compromised. If indicators are present, treat the hypervisor as compromised and investigate its guests for possible follow-on access or tampering.

Could this happen to other software? Yes. Any updater that relies only on transport security without independently authenticating the downloaded package is exposed to similar supply-chain delivery risks.