The Road Became the Destination

How a BGP Hijack Turned Virtualizor’s Trusted Update System Against Its Customers

September 3, 2026 | Jonathan Brown

At 20:57 UTC on August 28, 2026, a new route appeared in the machinery that tells the Internet where to send traffic. It claimed a relatively small block of addresses—162.55.80.0/24—inside a much larger block operated by the German hosting company Hetzner. Those addresses happened to serve systems belonging to Softaculous, including its customer and billing portal and the update infrastructure for Virtualizor, a control panel used by hosting companies to manage virtual private servers.

For much of the next thirty-three hours, in two major waves totaling roughly twenty-two hours of effective diversion, a substantial portion of the Internet believed the new directions. Requests intended for Softaculous traveled instead toward a server controlled by an attacker. The impostor did not present an obviously fake website with a broken padlock. It obtained a real, publicly trusted certificate from Let’s Encrypt covering twenty-six Softaculous-associated names, including virtualizor.com, api.virtualizor.com, and files.virtualizor.com. Connections completed without a certificate warning.

That still should not have been enough to compromise a hypervisor. A properly designed software updater treats HTTPS as protection for the journey and a cryptographic package signature as proof of the cargo. Virtualizor’s update clients did not yet verify package signatures. When an installation reached the attacker’s convincingly encrypted imitation of the update service, it could accept a malicious package as genuine.

The package modified legitimate Virtualizor files. Those files were later executed by normal root-level automation. On systems examined by hosting provider AlbaHost, the injected code planted a root SSH key, installed Java 17 if necessary, downloaded a Java remote-access payload, created persistent system services, added an unauthorized user, and enabled interactive access. AlbaHost reported the same malicious modifications on five of its thirty-four Virtualizor hypervisors.

No buffer overflow or novel remote-code-execution vulnerability was required. The attackers combined weaknesses across Internet routing, route authorization, certificate issuance, TLS’s trust assumptions, and package authentication. Each layer behaved largely as configured; together, they delivered hostile code as root to machines built to control other machines.

Changing the Internet’s Road Signs

The Border Gateway Protocol, or BGP, is how large networks tell one another which Internet addresses they can reach. The Internet is not one network with a central routing authority. It is a federation of autonomous systems—telecommunications companies, cloud providers, hosting companies, universities, governments, content networks, and other large operators—each identified by an Autonomous System Number.

An autonomous system advertises routes to neighboring systems. Those neighbors may pass the routes onward. A router receiving several possible routes considers policy, path attributes, and path length, but one rule precedes ordinary BGP path selection: the most specific matching destination wins.

Suppose a provider announces 162.55.0.0/16, containing 65,536 addresses. If another network announces 162.55.80.0/24, covering 256 addresses inside it, routers accepting both send traffic for those addresses toward the /24. One sign says “the city is straight ahead”; the other gives a different turn for one street. The more precise sign wins.

According to Virtualizor’s reconstruction and independent analysis by Kentik and BGPKIT, the unauthorized /24 appeared through AS62390, identified publicly as NexonHost, and was propagated through transit provider AS6204, ZET.NET. The visible path ended with AS24940, Hetzner’s real autonomous-system number. An example path recorded by RIPE’s routing collectors was:

... 6204 62390 24940

The path is stored from the observer back toward the asserted origin, so AS24940 at the far end made Hetzner appear to remain the origin. AS62390 appeared immediately before it, as though it were a legitimate upstream or adjacent network carrying Hetzner’s route. Routing records show where the announcement entered and traveled through the public system. They do not prove whether AS62390 itself was deliberately operated by the attacker, compromised, abused by a customer, or deceived. Nor do they identify the person who prepared the impostor service and payload.

The first forged announcement was recorded at 20:57:30 UTC on August 28. The route flapped—appearing, disappearing, and changing visibility—but propagated broadly. Virtualizor’s survey of 368 RIPE Routing Information Service peers found that all had carried the hijacked route at some point. Individual snapshots reached roughly seventy-two percent of that observer set. Those percentages describe routing visibility among selected collectors, not the percentage of all Internet traffic and certainly not the percentage of Virtualizor installations compromised.

The first wave continued until Hetzner began announcing the same /24 directly at approximately 08:50 UTC on August 29. That legitimate equally specific route sharply reduced diversion. After an approximately eleven-hour lull, the hostile announcement returned around 20:00 UTC and continued intermittently until it was withdrawn shortly before 06:10 UTC on August 30.

The use of a previously unseen, more-specific route was not merely convenient. It made the attack global enough to defeat a certificate defense designed to stop narrower BGP attacks.

How the Hijack Remained RPKI-Valid

Resource Public Key Infrastructure, or RPKI, is often described as the main cryptographic defense against BGP hijacking. Address holders create signed Route Origin Authorizations, or ROAs, saying which autonomous system may originate a prefix. Networks performing Route Origin Validation can reject a route whose claimed origin is inconsistent with the applicable ROA.

Hetzner had a ROA covering 162.55.0.0/16, authorizing origin AS24940 and allowing announcements as specific as /24. The attacker’s route claimed the prefix 162.55.80.0/24, kept AS24940 at the origin end of the path, and therefore satisfied both checks. The asserted origin was authorized and the prefix length was within the allowed maximum. RPKI correctly returned “valid” for the facts it was designed to evaluate.

What it did not answer was whether AS62390 was authorized to sit immediately upstream of Hetzner and announce that route through AS6204. Basic Route Origin Validation validates the origin; it does not authenticate every relationship in the path.

This is the incident’s most instructive technical wrinkle. A crude hijacker might simply originate Hetzner’s prefix from its own autonomous system. A network enforcing RPKI could see the unauthorized origin and reject it. Here, the real origin remained at the end of a forged path. The route passed origin validation while steering traffic through the attacker.

Hetzner’s permissive maxLength 24 also mattered. It authorized any more-specific prefix down to /24 under that /16 as long as AS24940 appeared as the origin. RFC 9319, an Internet Best Current Practice, recommends “minimal ROAs” that authorize only prefixes actually originated and generally advises avoiding the maxLength field unless it is genuinely necessary. If the legitimate network announces only the /16, a ROA confined to that exact /16 would make the hostile /24 invalid.

That would not make the Internet invulnerable. RPKI filtering is not universal, and a determined attacker may find other ways to manipulate paths. But strict ROAs would substantially reduce propagation among networks that reject invalid routes. A hijack reaching only a minority of the Internet is also more likely to fail the certificate authority’s geographically distributed checks.

Autonomous System Provider Authorization, or ASPA, addresses another part of the problem by letting an autonomous system publish its authorized providers. It could expose implausible path relationships even when the origin is legitimate. Support is entering operational use, but the principal verification specifications remained active IETF drafts. It is not yet a universal shield.

The more immediate failure was old-fashioned filtering. A transit provider should know which prefixes its customer is entitled to announce. Accurate customer prefix lists, Internet Routing Registry data, RPKI checks, customer-cone validation, and alerts for an unprecedented more-specific route can prevent or rapidly expose this behavior. In this case, the public BGP evidence was present the instant the first announcement appeared. The security consequence was recognized days later. The data existed; the operational link between routing alerts and software-supply-chain risk did not.

Why Let’s Encrypt Issued a Valid Certificate

The attacker still faced a problem. Redirecting traffic to a counterfeit server would ordinarily produce TLS failures. A browser, API client, or updater asking for files.virtualizor.com expects a certificate signed by a trusted certificate authority and valid for that name. The attacker did not possess Softaculous’ private key.

Instead, the attacker asked Let’s Encrypt for a new certificate.

Public certificate authorities issue Domain Validation certificates after the applicant proves control over the requested name. In an HTTP-based ACME challenge, the authority requests a fresh token from a prescribed location beneath the domain. During the hijack, DNS still pointed Softaculous names to the expected addresses, but the route to those addresses led to the impostor. Let’s Encrypt’s validation requests followed it; the attacker answered correctly and passed the test.

This does not mean the attacker forged a Let’s Encrypt signature, stole the certificate authority’s signing key, or broke TLS encryption. Let’s Encrypt issued a genuine certificate after receiving technically valid proof through a corrupted network path. The certificate then allowed the attacker to establish genuinely encrypted sessions whose other endpoint was nevertheless malicious.

Let’s Encrypt has understood this threat for years. In 2020 it became the first public CA to deploy multi-perspective validation at scale. The CA/Browser Forum later made it an industry requirement. By June 15, 2026, covered public authorities had to use at least four remote perspectives, with successful corroboration spanning at least two Regional Internet Registry service regions.

Multi-perspective checking is effective against a localized route hijack. If two validation systems reach the attacker but others still reach the real site, the disagreement can stop issuance. In the Virtualizor case, however, the unauthorized route was an uncontested, more-specific /24 and propagated to enough of the Internet to control the validation quorum. Every observer can independently reach the wrong server. Agreement among witnesses is not useful when the road carrying all the witnesses has been redirected.

So what is “up” with Let’s Encrypt? The fair answer is not that it casually handed a certificate to an anonymous criminal. Its automated system checked the kind of control a Domain Validation certificate is meant to establish, used an advanced multi-perspective defense, and was defeated by an unusually broad routing attack specifically constructed to preserve RPKI validity. As of the reporting cutoff, no detailed public Let’s Encrypt incident analysis had been located. Virtualizor said it reported the certificate for revocation.

The 2018 USENIX paper “Bamboozling Certificate Authorities with BGP” demonstrated the problem and recommended both multiple vantage points and real-time BGP monitoring by CAs. Virtualizor exposes the remaining boundary: a never-before-observed /24, unfamiliar path adjacency, or severe route flapping during validation should prompt delay or stronger proof.

Domain owners also have a little-used defense. Let’s Encrypt supports a CAA accounturi parameter restricting issuance to a particular ACME account, so temporary route control is insufficient without that account key. validationmethods can limit acceptable challenges. DNS-based validation, DNSSEC, and account binding can separate certificate authorization from the web server’s route, while shifting trust to DNS and ACME-account security.

Certificate Transparency provides detection, not prevention. It can expose unexpected issuance, but a fast attacker may use the certificate before a human responds. Revocation is imperfectly enforced and cannot undo damage completed during the diversion.

Turning a Valid Connection into a Malicious Update

Even after the BGP hijack and certificate issuance, the attackers had only created a convincing delivery channel. The decisive failure occurred in the update client.

TLS answers two questions: is the connection encrypted, and did a trusted certificate authority attest that the server presented a valid certificate for the requested name? It does not prove that a downloaded file was created, reviewed, or released by the software vendor. Secure update systems verify a digital signature over the package or trusted metadata using a key whose authority does not depend on the download server.

Virtualizor acknowledged that its clients did not yet cryptographically verify update packages. Once the impostor had the route, domain certificate, and cloned endpoint, there was no independent authentication layer left. Publishing a SHA-256 hash beside the package on the same hijacked server would not have helped; the attacker could replace both file and hash. The client needed a signature verifiable with a trusted vendor key already installed locally.

Provider reporting indicates that the counterfeit update advertised itself as 3.2.9.8. Five affected AlbaHost nodes reported a successful update but remained on 3.2.9.7, making the version mismatch itself a useful clue. The package inserted @exec() commands into globals.php and _universal.php, and placed similar logic in the zzvirtservice startup script. Virtualizor’s ordinary root cron execution of virt_check.php then triggered the hostile commands.

On one documented host, the sequence began at 22:23:01 Central European Summer Time on August 29. The root SSH key appeared in the same second. Within roughly thirty-five seconds, the system had reloaded systemd, installed Java 17, started the malicious Java service, and written an installation marker. Nine minutes later, an unauthorized proxyuser account existed. A password-authenticated SSH session from 193.32.127[.]248 remained open for approximately three hours and fifteen minutes.

The payload was stored at /usr/lib/jvm/.cache/jre-runtime.dat and persisted as /etc/systemd/system/java-jre-update.service, configured to restart continuously. Its SHA-256 was reported as b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7. The Java process connected to 31.77.220[.]138:2025. Other published indicators include cdn[.]nerat[.]cc, connect[.]ne-rat[.]xyz, /tmp/widdow.jar, /usr/lib/jvm/.cache/.installed, and /tmp/.vz_svc_done.

Those indicators establish behavior, not authorship. The use of apparently commodity remote-access infrastructure might indicate an ordinary criminal operator, a deliberately disposable toolset, or an attempt to look ordinary. The sophistication of the delivery operation and the sophistication of the payload need not match. Skilled access brokers routinely use common malware after difficult initial access; state operators sometimes do the same; criminals can also rent specialized routing access. No responsible group has been identified.

How Novel Was It?

None of the ingredients is new. Their use against a virtualization-management software update is unusual.

Researchers demonstrated BGP-assisted certificate theft against major certificate authorities before 2018. KLAYswap suffered a closely related cross-layer attack in February 2022: adversaries hijacked routing, obtained a valid certificate, served malicious JavaScript, and stole roughly two million dollars in cryptocurrency. Celer Bridge was attacked through a more-specific BGP route in August 2022, affecting thirty-two users and stealing approximately $235,000. In those cases, the ultimate target was a web front end and transactions performed by visiting users.

There is also precedent for using BGP to deliver malware. Ars Technica’s review points to a 2015 operation in which Hacking Team used route manipulation against a targeted infection. BGP hijacks have redirected DNS and cryptocurrency traffic, intercepted communications, and caused large accidental outages.

Virtualizor advances the pattern in three ways. First, it targeted a software-distribution path rather than merely a human-facing website or transaction interface. Second, the recipients were hypervisor management systems running privileged vendor automation. Third, the forged path was engineered to remain RPKI-valid, while broad propagation defeated multi-perspective certificate validation.

The result is not a wholly novel technique in the academic sense. It is a rare, operationally successful composition of techniques whose interaction defenders have discussed for years. Its novelty lies in target selection, end-to-end execution, and consequence. The attacker did not merely impersonate a vendor. The attacker briefly made the Internet agree that the impostor was the vendor, then exploited a product design that equated a secure connection with authentic software.

Who Did It?

We do not know.

AS62390 is the apparent injection point in the public route, and AS6204 propagated the announcement. That is not equivalent to identifying the attacker. The route could have been originated by an autonomous-system operator, a compromised router or account, an abusive customer, or someone who persuaded an upstream to accept false routing information. The inclusion of Hetzner’s AS24940 at the path’s end indicates planning, but it does not provide identity.

The domains, IP addresses, SSH key, Java payload, and proxyuser account are investigative leads. None establishes a named group. The operation required knowledge of BGP policy, Softaculous infrastructure, certificate validation, and Virtualizor’s update behavior. It also required access to a network position capable of exporting the route. That combination supports a deliberate, prepared operation rather than an accidental route leak followed by opportunistic compromise.

Beyond that, attribution would be speculation. No government, vendor, or independent research organization reviewed for this article publicly attributed the attack to a state, ransomware group, access broker, or named criminal organization. The absence of a ransom demand and the focus on durable root access are notable but not dispositive. Hosting infrastructure is valuable for espionage, cryptocurrency theft, proxy services, botnets, data theft, and resale to other attackers.

What Has the Response Been?

Hetzner countered the more-specific route by announcing the legitimate /24, causing diversion to collapse. Normal routing was restored after the hostile route’s final withdrawal on August 30. Virtualizor reported the certificate to Let’s Encrypt for revocation, notified relevant network operators and CERTs, invalidated client-area sessions from the affected window, and published its routing reconstruction and known indicator.

Virtualizor released 3.2.9.9, also described in its release naming as 3.2.9 Patch 9, with a Security Analyzer and mitigation tooling. It provided a scanner for known artifacts, advised operators to rotate and restrict API credentials, and said it would implement code signing for all packages and migrate to improved infrastructure. As of September 3, package signing was a promised control, not a confirmed property of a released updater.

The company cannot produce a complete victim list because diverted requests never reached its own servers or logs. It therefore asks every Virtualizor operator to check every node. It has not identified malicious packages for other Softaculous products, but its investigation remains open. Users who accessed the client or billing area during the diversion window were told to reset passwords and review activity; payment processing occurred through gateways, but the hostile site could still have received entered traffic.

AlbaHost isolated affected nodes, stopped and quarantined payloads, removed known persistence, reset Virtualizor credentials, searched all thirty-four hypervisors, began log review, and notified customers. Crucially, it also stated that deleting known artifacts cannot restore trust after root compromise. A clean rebuild is the only reliable long-term remediation.

That is the correct standard. A negative scanner result means the scanner found none of the indicators it knows. It cannot prove that an interactive attacker with root access installed no additional key, kernel module, boot persistence, altered binary, stolen credential, or access path. Nor can “no confirmed modification of customer VPS instances” be translated into “customer VMs were proven clean.” Hypervisor root sits beneath the guest trust boundary.

What Defenses Would Actually Work?

The strongest answer is layered because no single organization controls the whole chain.

For software vendors, sign every update and make verification mandatory. Reject packages or metadata lacking a valid signature from a trusted vendor key. Keep signing keys separate from public web infrastructure, preferably offline or in hardened hardware. The Update Framework adds delegated roles, threshold signing, version counters, and expiration metadata against rollback, freeze, mix-and-match, and partial key-compromise attacks. TLS remains necessary but no longer defines software authenticity.

For network operators, create strict ROAs and reject invalid routes. Authorize only prefixes actually originated. Avoid broad maxLength settings that pre-authorize dormant more-specifics. Enforce Route Origin Validation and require upstreams and peers to do likewise.

Filter customers by what they are entitled to announce. Transit networks should maintain accurate prefix and autonomous-system filters, reject unexpected origins and paths, enforce maximum-prefix limits, and investigate a customer suddenly advertising address space belonging to a major unrelated provider. RPKI validity should not override basic plausibility.

Monitor for the attack that RPKI calls valid. Alert when a never-before-seen more-specific appears inside an aggregate, especially when the penultimate autonomous system has no historical adjacency to the legitimate origin. Correlate route anomalies with certificate issuance, DNS changes, software-update telemetry, and origin-server traffic drops. A routing alert for an update endpoint is a security incident, not merely a network-engineering ticket.

Adopt path validation as it matures. ASPA can help networks validate provider relationships rather than only route origins. RFC 9234 BGP Roles and the Only-to-Customer attribute help prevent route leaks. Neither replaces customer filtering, but both reduce the degree to which the Internet must infer commercial routing relationships from unverified path strings.

For certificate authorities, combine MPIC with routing intelligence. Multi-perspective validation stopped many possible localized attacks, but quorum agreement is inadequate when a forged more-specific dominates globally. A fresh subprefix, abnormal path adjacency, or heavy route flapping during validation should trigger delay, additional perspectives, or a stronger challenge. The 2018 research proposed this pairing explicitly.

For domain owners, bind issuance to an ACME account and monitor Certificate Transparency. CAA accounturi restrictions can make temporary route control insufficient. Restrict acceptable validation methods where operations permit. Monitor CT logs continuously for unexpected names or issuers, and rehearse emergency revocation. These controls are particularly important for update, API, identity, billing, and administrative domains.

For hosting providers, assume the management plane is Tier Zero. Use controlled update proxies where practical, canary releases, and alerts when an update claims success without producing the expected version. Separate management credentials from guests, minimize hypervisor secrets, constrain panel APIs, and retain process, network, authentication, and filesystem telemetry sufficient to reconstruct root activity.

For this incident specifically, every node that checked for updates during a diverted interval is in scope. Look for the published service, payload, hash, domains, IP addresses, SSH material, altered Virtualizor files, proxyuser, and the false-success version mismatch. Preserve evidence before cleaning. Rotate panel, root, API, database, backup, customer, and connected-service credentials accessible from confirmed hosts. Review guests and management peers. Rebuild any root-compromised hypervisor from trusted media, then restore only verified data and workloads.

The Industry Buzz—and the Real Lesson

The incident has drawn unusually broad attention across routing specialists, hosting-provider forums, and mainstream cybersecurity publications. Kentik focused on the RPKI-valid forged origin and the interaction between strict ROAs and multi-perspective certificate validation. BGPKIT reconstructed the first route announcement from raw RIPE and Route Views records and emphasized a practical detection rule: an unprecedented more-specific prefix plus an unfamiliar origin-adjacent autonomous system. Ars Technica described the event as an unusual malware-delivery supply-chain attack. SecurityWeek, BleepingComputer, Risky Business, and The Hacker News all highlighted the valid certificate and unsigned updater. Hosting providers on LowEndTalk concentrated on indicators, collaborative scoping, and whether operators would accept the cost of rebuilding compromised nodes.

The serious discussion is not blaming Let’s Encrypt or declaring RPKI useless. It is recognizing that controls can be individually real and collectively insufficient. RPKI validated the origin but not the path relationship. Multiple observers agreed because the same global route misled them. TLS encrypted the connection to the attacker. The updater verified the channel but not the object. A scanner found known persistence but could not restore root trust.

The most important defense was also the simplest and the one Virtualizor lacked: verify the software itself.

The episode matters beyond hosting because each institution applies a different definition of success. The router asks whether a route is preferable. RPKI asks whether the origin is authorized. The CA asks whether the applicant demonstrates present domain control. TLS asks whether the server has a valid certificate and key. The updater asks whether the server delivered an update.

Security fails when the final question is never asked: Is this exact package cryptographically authorized by the vendor to run here?

The attackers changed the route, borrowed the domain’s identity, and placed a counterfeit package on the expected path. They needed each layer to accept its narrow proof—and the last layer to ask nothing further.

The road became the destination. The padlock authenticated the detour. Root accepted the parcel.

That is not merely a clever BGP story. It is a warning about every automatic update system whose ultimate trust decision is still, in effect, “it arrived over HTTPS.”

Jonathan Brown is a cybersecurity researcher and investigative journalist at bordercybergroup.com.

If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — subscribe, comment, or buy us a coffee! Thanks.