Originally published at https://monstadomains.com/blog/bgp-hijacking-attack/
At 20:57 UTC on 28 August 2026, a network told the rest of the internet that a block of German IP addresses belonged to it. That was not true. For the next 33 hours, a BGP hijacking attack sat quietly between hosting providers and the servers that fed them software updates, and a number of those providers downloaded a package that handed root access to a stranger. There was no certificate warning. There was no visible failure at all.
The target was Softaculous, the company behind Virtualizor, a control panel that hosting providers use to create, sell and manage VPS instances. The attacker did not breach Softaculous. They did not steal a password or find a bug in the code. They convinced enough of the internet’s routers that traffic bound for Softaculous should arrive at their server instead, and the rest of the internet obligingly complied. That is what makes a BGP hijacking attack different from nearly everything else in a normal threat model.
What The BGP Hijacking Attack Actually Did
Routing data confirmed through RIPE Stat shows an autonomous system beginning an unauthorised announcement for 162.55.80.0/24 at 20:57:30 UTC on 28 August. That prefix sits inside Hetzner address space and contained the IP addresses Softaculous used for both its update infrastructure and its client portal. Networks around the world started forwarding Softaculous traffic to the attacker. The diversion ran intermittently until 06:10 UTC on 30 August, roughly 22 hours of actual redirection inside a 33 hour window, with an eleven hour stretch in the middle during which almost nothing was diverted.
That intermittency matters more than it first appears. A BGP hijacking attack does not need to run continuously to succeed. It only needs to be live at the moment a server checks for an update, and hosting panels check on schedules their operators rarely think about. Softaculous later confirmed that a malicious Virtualizor update package was delivered to a small number of installations that checked for updates while their traffic was being diverted, describing the incident as affecting a handful of servers rather than the general Virtualizor user base.
The Valid Certificate That Made It Invisible
Here is the part that should genuinely unsettle you. While the attacker controlled the route, they obtained a valid Let’s Encrypt certificate for Softaculous domains. Domain validation asks a simple question: does whoever answers at this IP address control the domain? During a BGP hijacking attack, the attacker is whoever answers at that IP address. The certificate authority did precisely what it was built to do and issued a technically valid certificate to the wrong party, which then let the fake update server bypass client side security checks without a murmur.
Why HTTPS Did Not Save Anyone
Every update client that connected saw a working padlock. No warning, no name mismatch, no broken chain. The transport was encrypted and authenticated against a certificate that really did belong to the domain being requested. HTTPS proved that the connection had not been altered in transit, which was true, and said nothing whatsoever about whether the machine on the other end was the right one. A BGP hijacking attack collapses that distinction, because it relocates the attacker to the very address the name legitimately points to.
This is worth sitting with, because it inverts a decade of security advice. Checking for the padlock is genuinely good practice and it would have failed every single administrator affected here. A BGP hijacking attack does not defeat TLS by breaking the cryptography. It defeats TLS by satisfying it honestly, having first taken ownership of the thing TLS was asked to verify.
Root Access, A Fake Java Service And A User Named proxyuser
The package delivered by the BGP hijacking attack carried injected code inside three otherwise legitimate Virtualizor files. On execution it added an attacker controlled key to the root account, installed Java 17 where it was absent, then downloaded and ran a Java payload as root. Persistence arrived through a systemd unit at /etc/systemd/system/java-jre-update.service, a filename chosen to look like routine maintenance to anyone skimming a directory listing. The payload also created an account named proxyuser, and investigators recorded SSH activity from 193.32.127.248.
AlbaHost, a hosting provider that published its own findings, reported that 5 of our 34 Virtualizor hypervisor nodes contained the same malicious modifications. Read that ratio again. Roughly one in seven of that provider’s hypervisors was compromised at root level, and every customer VPS running on those nodes sat underneath the compromise. A BGP hijacking attack that reaches a hypervisor does not compromise one website. It compromises everything hosted on it, silently, at the layer beneath the customer.
How This BGP Hijacking Attack Was Spotted
Nobody caught this from inside the affected servers. It was caught from the outside, in public routing telemetry, because BGP announcements are visible to anyone watching collectors like RIPE Stat. The unauthorised announcement of 162.55.80.0/24 is a matter of public record with a timestamp attached to the second. That is the strange asymmetry of a BGP hijacking attack: close to undetectable on the victim machine, and completely obvious in the global routing table, provided somebody happens to be looking at the right prefix.
Reading The Route History
The eleven hour quiet period in the middle of the window is a useful detail for anyone reconstructing exposure. Providers cannot simply assume that any check performed during the 33 hour window was poisoned, and equally cannot assume that one performed outside the busiest hours was safe. Reconstructing a BGP hijacking attack means correlating your own update timestamps against public route history, which is exactly the sort of evidence most operators have never had cause to gather before.
Why A BGP Hijacking Attack Beats Your Threat Model
Most security guidance assumes an attacker must get through something: a firewall, a login, an unpatched service. Routing sits underneath all of that. BGP has no built in authentication. It is a system in which networks announce the addresses they can reach and other networks broadly take their word for it. Every hardening step the affected providers had taken was still fully intact while the BGP hijacking attack was running. Their servers requested a legitimate file from a legitimate hostname over a legitimately certified connection, and received a backdoor.
The DNS And Registrar Angle
Domain owners tend to treat DNS as the layer deciding where traffic goes. It decides where traffic is addressed. Routing decides where it actually lands. Your DNS records can be perfect, your registrar lock enabled and your nameservers untouched, and a BGP hijacking attack will still place somebody else at the far end of the connection. Auditing what your domain currently resolves to is a reasonable starting point, and a DNS lookup pairs well with revisiting the registrar security weaknesses exposed in earlier hijacking cases.
Routing Security Is Still Effectively Optional
A fix exists and the industry has been deploying it slowly for a decade. RPKI lets address holders cryptographically declare which networks are permitted to announce their prefixes, and Route Origin Validation lets everyone else reject announcements that fail the check. Coverage is genuinely improving. As of June 2026, 67.43% of announced prefixes in the global routing table were covered by a signed Route Origin Authorization, which works out at 1,065,730 of 1,580,470 routes.
Enforcement is where it falls apart. Signing a route helps only if other networks bother to check the signature, and only around a quarter of systems actually enforce Route Origin Validation. Just 12.3% of autonomous systems achieve full validation coverage on their routes, while 36.2% perform no validation at all. That gap is the exact space a BGP hijacking attack operates in. Two thirds of the routing table is signed, and most of the internet is still not reading the signatures it is handed.
What Softaculous Did Next
Virtualizor shipped Patch 9 on 1 September with a bundled Security Analyzer that scans for the known indicators, then published guidance and scanner details the following day. The vendor reported the fraudulent certificate for revocation and released file hashes and malicious domains as indicators of compromise. It also committed to cryptographic signing for all future packages, alongside a migration to better infrastructure.
That commitment is the real lesson of this BGP hijacking attack. Package signing would have made the entire operation fail loudly. The attacker could still have diverted the traffic and still have held a valid certificate, but could not have produced a package the client would accept as authentic. Softaculous acknowledged that cryptographic package signing remained future work at the time of the patch, which is a sentence no software distributor should be writing in 2026.
What To Do After This BGP Hijacking Attack
If you run Virtualizor, the checks are specific. Look for /etc/systemd/system/java-jre-update.service. Inspect the root account’s authorised keys for anything you did not put there. Search for an account named proxyuser, unexpected scheduled tasks and outbound connections to unfamiliar addresses. Rotate and restrict API credentials. Anyone who signed into the Softaculous client area between 28 and 30 August should reset that password and watch their financial statements, because the client portal shared the diverted address range.
If you do not run Virtualizor, the response to this BGP hijacking attack is broader but no less urgent. Verify what you install rather than trusting transport security alone, favour vendors who sign their packages, and treat every automated update channel as a live entry point into your infrastructure. The operators hit here were doing nothing wrong by conventional standards, which is exactly why those standards have to move. Working through the domain security measures most teams skip is a sensible companion exercise.
The Takeaway
Three things are worth carrying away. A BGP hijacking attack requires breaking into nothing, so your patch level and password hygiene offer no protection against it. A valid TLS certificate proves you reached the address a name points to, not that the address is in trustworthy hands. And an unsigned update channel is a standing invitation, because the moment routing is subverted that channel becomes a delivery mechanism for whatever the attacker wants to run as root.
Routing attacks have moved from conference demonstrations to a working method for compromising production hypervisors, and the defensive gap is measurable in the two thirds of networks that still do not validate what they are told. At MonstaDomains we read this BGP hijacking attack as an argument for reducing how much of your stack depends on trusting any single channel. A sensible next step is checking what your SSL certificates actually prove about the servers you connect to.
Top comments (0)