> ## Content Index > Fetch the complete content index at: https://sargeson.com.au/llms.txt > Use this file to discover other available public pages before exploring further. # The Softaculous BGP hijack nobody's monitoring caught - URL: https://sargeson.com.au/the-softaculous-bgp-hijack-nobodys-monitoring-caught/ - Published: 2026-09-01T12:23:35.000Z - Updated: 2026-09-02T00:39:20.000Z - Author: Ashley Sargeson - Tags: Cybersecurity Between 28 and 30 August 2026, the licensing and update infrastructure behind the Virtualizor, Webuzo and Softaculous control panels was hijacked at the routing layer. I first reconstructed what happened from public routing data, while it was still just a set of anomalies with no official word. Softaculous and Virtualizor have since confirmed the hijack in advisories on 31 August, and confirmed the part routing data can't show: a tampered Virtualizor update reached a small number of hosting servers. The host-level forensics come from one of the affected providers, AlbaHost, who posted a detailed writeup on LowEndTalk. ## The short version Someone convinced most of the internet's routers that they were Hetzner, the hosting provider Softaculous runs on, for one specific block of IP addresses. Across two waves inside a \~33-hour window, that traffic went to a Romanian attacker instead of the real servers, and every automated routing defence read the redirect as legitimate. Before it was over, malicious code had been injected into Virtualizor's own files and executed as root on a small number of hypervisors. The hijack is over. But three TLS certificates minted during the window are still valid and unrevoked as of 1 September, and whoever holds them can silently intercept licensing traffic through to late November. If you run WHM/cPanel hosting with any of these panels installed, your nodes were phoning home to attacker-controlled infrastructure during the window, and any Virtualizor node should be treated as potentially in scope for a malicious update. The audit, IOCs and rotation steps are at the end. A quick primer for the sections below, if Border Gateway Protocol (BGP) isn't your daily driver. The internet is carved into IP blocks called prefixes, written as `162.55.0.0/16` (65,536 addresses) or `162.55.80.0/24` (256 addresses). The smaller the number after the slash, the bigger the block. Networks, each identified by an Autonomous System (AS) number, announce over BGP which prefixes they host, and routers worldwide trust those announcements. Two facts do all the damage here. Routers always prefer the most specific prefix, so a /24 overrides a /16 covering the same space. And the main defence, Resource Public Key Infrastructure (RPKI), only checks which network is allowed to originate a prefix. It says nothing about the path the traffic actually takes to get there. --- ## The Target Softaculous runs one IP for effectively its entire brand portfolio: `162.55.80.8`, a Hetzner (AS24940) address in Falkenstein. Everything resolves there: - `virtualizor.com` and its `api` and `files` endpoints - `softaculous.com` with various subdomains (`api`, `files`, `server`, `licenses`) - `webuzo.com` - `sitepad.com` - `pagelayer.com` - `popularfx.com` - `backuply.com` - `ampps.com` A hosting node checking a licence or downloading a panel update is talking to this one address. Before 28 August, Hetzner announced only `162.55.0.0/16` for this space: a single aggregate seen continuously by RIPE RIS peers, no more-specifics. There was no /24 of `162.55.80.0` anywhere in the global table. ## The Hijack At 20:57:30 UTC on 28 August, a `162.55.80.0/24` announcement appeared carrying the path `20912 6204 62390 24940`. The route was injected by AS62390 (NexonHost Srl) and propagated by its Romanian peer AS6204 (INTERKVM HOST SRL), with AS24940 (Hetzner) kept on the path tail as the apparent origin so the announcement would look legitimate. AS62390 normally originates 37 of its own /24s, and `162.55.80.0/24` isn't one of them, which is what made the adjacency to Hetzner's origin anomalous. From there it propagated through a dozen major transit providers, including GTT, Sparkle, RETN, Liberty Global and Hurricane Electric. The hijack didn't run continuously. Both vendors' reconstructions from RIPE routing data describe two waves separated by an \~11-hour lull: | Period (UTC) | What Happened | | --------------------------- | --------------------------------------------------------------------------------------------------------- | | 28 Aug 20:57 - 29 Aug 08:50 | First wave. The fake route flaps constantly but is accepted by nearly every network that receives it. | | 29 Aug 09:00 - 20:00 | Lull of roughly 11 hours. Hetzner announces the /24 itself, then both routes briefly fall back to the /16 | | 29 Aug 20:00 - 30 Aug 06:10 | Second wave. The fake route resumes for about 10 hours | | 30 Aug 06:10 onward | Withdrawn. Normal routing restored and verified clean health | Virtualizor reconstructed the incident minute-by-minute from RIPE's 368 monitoring points. Every single one carried the fake route at some point. At the peak of each wave, roughly 72% were following the attacker, and across the full incident the fake route won about 28% of the time on average. The route was unstable; Virtualizor counted around 10,600 withdrawals across the window. That instability is why diversion was intermittent rather than constant for any single server, and why only a handful of update checks happened to land on the attacker. By 31 August the prefix was Hetzner's alone, with none of the monitored routes traversing AS62390. One detail the vendor was pointed about, Hetzner didn't proactively notify them. Hetzner's effective mitigation, announcing the /24 directly, landed around 08:50 UTC on 29 August, roughly 12 hours after onset, and by Virtualizor's account only after they reported and escalated repeatedly. ## Why every control failed This is the part worth understanding, because it will happen again. ### **RPKI said valid.** RPKI is the system that's supposed to stop exactly this. It lets a network cryptographically declare which AS is allowed to originate its prefixes, and routers reject announcements that don't match. Hetzner's declaration (its Route Origin Authorization) is `162.55.0.0/16`, origin AS24940, with `maxLength 24`, meaning > "any sub-block down to /24 is fine, as long as AS24940 originates it." The attacker kept AS24940 as the apparent origin, so route-origin validation returned valid. The check only looks at who claims to originate the route, not at the fake AS path underneath it, so it passed. ### **The more-specific wins.** Routers always prefer the most specific route to a destination, so the attacker's /24 overrode Hetzner's /16 wherever it was accepted. That's normal routing behaviour, which is precisely what makes it abusable. No path manipulation required beyond the origin forgery. ### **MOAS detectors stayed silent.** Most hijack-detection tooling watches for MOAS events: Multiple Origin Autonomous System, where the same prefix is suddenly announced by a different network than usual. That's the classic hijack signature. Here the origin AS never changed. Both the real /16 and the forged /24 showed origin AS24940, so any alarm keyed on a different origin saw nothing unusual. ### The certificate was real. The attacker's server obtained a valid TLS certificate from Let's Encrypt for Softaculous's domains. The certificate authority's automated ownership check was itself routed through the diverted traffic, so to prove domain control, Let's Encrypt connected to the attacker. Affected connections showed the padlock and no browser or client warning. ### The update wasn't signed. Virtualizor's update system didn't cryptographically verify packages, so tampered code served over that "valid" connection wasn't rejected. This is the one that mattered. Signed updates would have caught the tampering no matter how the traffic was routed. That missing check is what turned a routing incident into a real compromise. Georgia Tech's GRIP observatory was the exception. It fired a `defcon` event at 20:55:00 UTC, six minutes before the first RIS announcement even landed. GRIP flagged it with confidence 50 and left it "unclassified", but the tags tell the story: `sub-path-longer`, `no-common-hops-super-pfx` and `rpki-all-oldcomer-valid-roa`. That's the tell worth monitoring for: a new more-specific whose AS path shares no hops with the covering prefix's paths, plus an AS adjacency that had no business sitting next to Hetzner's origin. ## The certificates Three Let's Encrypt certificates were issued inside the hijack window, and they cover the entire Softaculous estate: | Issued (UTC) | SANs | Serial | | --------------- | ---- | ------------------------------------ | | 28 Aug 20:00:35 | 21 | 051855DC362029C06B619F08DC6DD2952BC1 | | 28 Aug 20:31:56 | 23 | 05826603FB350AB489FEF8979D963BAFB37B | | 28 Aug 22:59:18 | 26 | 06D0A943421866BBF060A1C94C888A6463C0 | Virtualizor's advisory confirms both halves of this. The attacker did obtain a valid certificate for its domains, and the interception was caught in the act on 29 August when someone spotted a host on the diverted route answering for Softaculous domains with the fraudulent cert. The 26-name certificate matches the full SAN list in the advisory's Appendix A. Virtualizor has reported all three to Let's Encrypt for revocation, but a live CRL check on 1 September shows they're still valid. The remaining tells: - Softaculous's certificate-transparency history is otherwise exclusively single-name certificates renewed by cron at roughly 03:00 UTC, plus per-brand Sectigo and Google Trust Services wildcards. A 21–26 SAN multi-brand bundle issued at 20:00/20:31/22:59 is a complete break from that pattern. - None of the three is deployed. A live probe against the real server on 31 August still returned the old single-name certificates from July and August. - The first two certificates predate the first RIS-observed hijack announcement by 57 and 26 minutes. The route was flapping from the outset, present intermittently before RIS peers logged a clean announcement, so validation traffic was already being diverted while the public view was still catching up. ## The damage The public routing data could only show that traffic was redirected. The vendor advisories and AlbaHost's forensics settle what the attacker did with it. Malicious `@exec()` commands were injected straight into legitimate Virtualizor files on the affected nodes: `_universal.php`, `globals.php` and the `zzvirtservice` startup script. The payload fired through Virtualizor's own root cron job, `virt_check.php`, not through any attacker SSH login. On one AlbaHost node that cron ran at 20:23:01 UTC on 29 August, and in the same second it wrote an attacker-controlled key to `/root/.ssh/authorized_keys`. Running as root, it then installed Java 17, pulled `widdow.jar` from `https://cdn[.]nerat[.]cc/installer/widdow.jar`, ran it, and stood up a systemd unit for persistence (`java-jre-update.service`) running a \~13.5 MB payload at `/usr/lib/jvm/.cache/jre-runtime.dat`, plus a rogue `proxyuser` account. The pattern hit 5 of AlbaHost's 34 hypervisors. About ten minutes after the automated infection, someone logged into `proxyuser` over SSH from `193.32.127[.]248` and stayed connected for roughly three hours. The tooling isn't bespoke. The payload resolves its C2 (`31.77.220[.]138:2025`) from `connect[.]ne-rat[.]xyz`, and nerat is a commodity remote-access-trojan service with a panel at `web[.]ne-rat[.]xyz`. The attacker bought their RAT off the shelf rather than building it. By the time AlbaHost published, the C2 had stopped responding and both the C2 IP and the CDN domain had been reported, so treat those two as historical indicators rather than live blocklist candidates. Don't trust the version number to tell you whether a box was hit. The rogue update announced itself as `3.2.9.8`, but all five affected AlbaHost servers reported the update "completed" and stayed on `3.2.9.7` afterward. Check the files on disk, not the reported version. The blast radius is harder to pin down. The malicious responses came from the attacker's server and never touched Virtualizor's logs, so the vendor can't produce a definitive list of affected machines and is treating every Virtualizor server as in scope. AlbaHost found no sign that customer VMs were modified, though another affected provider reported its own MySQL database may have been exported. With root on the host, anything reachable from it has to be treated as exposed. There's no evidence any other Softaculous product received a malicious package, though that investigation is ongoing. There's also the login area: the attacker-controlled server answered for `softaculous.com/clients` during both waves, so anyone who signed in during the window may have sent their password straight to the attacker. No database was taken from Softaculous and no card data is stored on their servers, but any credentials used in that window should be treated as compromised. ## If you run any of this The window to audit is **28 Aug 20:57 UTC - 30 Aug 06:10 UTC**. Any licence sync, panel update or template/app download through the following in that window is untrusted and should be re-pulled and hash-compared: - `*.virtualizor.com` - `*.softaculous.com` - `*.webuzo.com` If you operate Virtualizor nodes, run the official scanning script and hunt for the attacker's persistence: `https://files.virtualizor.com/security/virtualizor_security_scan.sh` Grep the Virtualizor install and the usual persistence locations for the known strings: ```bash grep -RsnE 'cdn\.nerat\.cc|widdow\.jar|jre-runtime\.dat|AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte' \ /usr/local/virtualizor /etc/systemd/system /root/.ssh 2>/dev/null systemctl status java-jre-update.service --no-pager pgrep -af 'java|jre-runtime|widdow' getent passwd proxyuser ss -tpna | grep -E '31\.77\.220\.138|:2025' sha256sum /usr/lib/jvm/.cache/jre-runtime.dat 2>/dev/null ``` Don't restart Virtualizor or `zzvirtservice` before checking the files. Restarting an infected startup script can re-run the payload. Reset all Virtualizor API keys in the master panel, restrict API access to trusted IPs, and remove any key you don't recognise. If you find signs of compromise contact Virtualizor support before you clean up so the evidence is preserved. And plan on a clean rebuild. Once root's been in play, deleting the files you found can't prove the box is clean. Rotate anything that transited those endpoints: licence keys, panel API keys and any admin credentials entered on a Softaculous-branded page. If you use NOC API keys, regenerate them. And anyone who signed into `softaculous.com/clients` during either wave should reset that account's password and change it anywhere it was reused. Report the three serials above to Let's Encrypt and Softaculous so they get revoked. Until they are, they stay usable for silent man-in-the-middle interception of licensing traffic through to late November. ### Indicators of Compromise Host-level indicators are from AlbaHost's forensic writeup on the affected nodes. The network indicators (`31.77.220[.]138`, `cdn[.]nerat[.]cc`) were reported and taken down by 31 August, so treat them as retrospective hunting material rather than live blocklist entries. And note `ne-rat[.]xyz` and `nerat[.]cc` are two separate domains. The first is the RAT's C2, the second stages the payload. | Type | Indicator | Comments | | -------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | | C2 | 31.77.220\[.\]138:2025 | Resolved via connect\[.\]ne-rat\[.\]xyz; QWINS LTD space; unresponsive by 31 Aug | | SSH login source | 193.32.127\[.\]248 | Interactive login to rogue proxyuser (\~3h session) | | Payload download | https://cdn\[.\]nerat\[.\]cc/installer/widdow.jar | Staged JAR; also written to /tmp/widdow.jar then removed | | Payload (on disk) | /usr/lib/jvm/.cache/jre-runtime.dat | \~13.5 MB, run as java -Xmx128M -jar | | SHA-256 | b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7 | Hash of AlbaHost's sample; per-node variants may differ | | Systemd unit | /etc/systemd/system/java-jre-update.service | Persistence; description "Java Runtime Environment Update Service", Restart=always | | SSH key fingerprint | SHA256:YQmy1hKF1h5cdJLxlZ5EScNoxe/UDWahjsWuQw2ERi8 | Fingerprint of the public key below | | SSH key (public) | ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte | Written to /root/.ssh/authorized\_keys | | Rogue account | proxyuser | Local account created by the payload | | Installation markers | /usr/lib/jvm/.cache/.installed | Also /tmp/.vz\_svc\_done (startup-script one-time marker) | | Injected files | /usr/local/virtualizor/\_universal.php | Also globals.php and zzvirtservice; injected @exec() payload | | Tooling origin | ne-rat\[.\]xyz | Commodity RAT service; panel at web\[.\]ne-rat\[.\]xyz | ### MISP Event ```json { "Event": { "info": "BGP hijack of Softaculous/Virtualizor/Webuzo licensing infrastructure", "date": "2026-08-30", "threat_level_id": "2", "analysis": "2", "distribution": "1", "Tag": [ { "name": "tlp:clear" }, { "name": "misp-galaxy:mitre-attack-pattern=\"BGP Hijacking - T1590.002\"" }, { "name": "misp-galaxy:mitre-attack-pattern=\"Compromise Software Supply Chain - T1195.002\"" }, { "name": "misp-galaxy:mitre-attack-pattern=\"Adversary-in-the-Middle - T1557\"" }, { "name": "misp-galaxy:mitre-attack-pattern=\"SSH Authorized Keys - T1098.004\"" }, { "name": "misp-galaxy:mitre-attack-pattern=\"Systemd Service - T1543.002\"" }, { "name": "misp-galaxy:mitre-attack-pattern=\"Ingress Tool Transfer - T1105\"" } ], "Attribute": [ { "type": "ip-dst|port", "category": "Network activity", "to_ids": true, "value": "31.77.220.138|2025", "comment": "C2; resolved via connect.ne-rat.xyz; QWINS LTD space; unresponsive by 31 Aug 2026" }, { "type": "hostname", "category": "Network activity", "to_ids": true, "value": "connect.ne-rat.xyz", "comment": "C2 resolver hostname" }, { "type": "ip-src", "category": "Network activity", "to_ids": true, "value": "193.32.127.248", "comment": "Interactive SSH login source for rogue 'proxyuser' account (~3h session)" }, { "type": "url", "category": "Payload delivery", "to_ids": true, "value": "https://cdn.nerat.cc/installer/widdow.jar", "comment": "Staged JAR download; written to /tmp/widdow.jar then removed" }, { "type": "domain", "category": "Payload delivery", "to_ids": true, "value": "cdn.nerat.cc", "comment": "Payload staging host; reported/taken down by 31 Aug 2026" }, { "type": "sha256", "category": "Payload delivery", "to_ids": true, "value": "b81a4e1fab9fc4e404d57224fe71e2c143aa93942bd46998789bdc944a7870c7", "comment": "AlbaHost sample of jre-runtime.dat; per-node variants may differ" }, { "type": "filename", "category": "Payload installation", "to_ids": false, "value": "/usr/lib/jvm/.cache/jre-runtime.dat", "comment": "Payload on disk ~13.5 MB; executed as: java -Xmx128M -jar" }, { "type": "filename", "category": "Persistence", "to_ids": false, "value": "/etc/systemd/system/java-jre-update.service", "comment": "Persistence unit; Description 'Java Runtime Environment Update Service'; Restart=always" }, { "type": "ssh-fingerprint", "category": "Artifacts dropped", "to_ids": true, "value": "SHA256:YQmy1hKF1h5cdJLxlZ5EScNoxe/UDWahjsWuQw2ERi8", "comment": "Fingerprint of attacker ed25519 public key written to /root/.ssh/authorized_keys" }, { "type": "text", "category": "Artifacts dropped", "to_ids": false, "value": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP13pPAm5jmInLQYD3XNb3HwrW4cAKDcphoT4kSKrnte", "comment": "Attacker public key written to /root/.ssh/authorized_keys" }, { "type": "text", "category": "Artifacts dropped", "to_ids": false, "value": "proxyuser", "comment": "Rogue local account created by the payload" }, { "type": "filename", "category": "Artifacts dropped", "to_ids": false, "value": "/usr/lib/jvm/.cache/.installed", "comment": "Installation marker" }, { "type": "filename", "category": "Artifacts dropped", "to_ids": false, "value": "/tmp/.vz_svc_done", "comment": "Startup-script one-time installation marker" }, { "type": "filename", "category": "Artifacts dropped", "to_ids": false, "value": "/usr/local/virtualizor/_universal.php", "comment": "Legitimate Virtualizor file with injected @exec() payload" }, { "type": "filename", "category": "Artifacts dropped", "to_ids": false, "value": "/usr/local/virtualizor/globals.php", "comment": "Legitimate Virtualizor file with injected @exec() payload" }, { "type": "filename", "category": "Artifacts dropped", "to_ids": false, "value": "zzvirtservice", "comment": "Virtualizor startup script with injected @exec() payload" }, { "type": "filename", "category": "Payload delivery", "to_ids": false, "value": "widdow.jar", "comment": "Downloaded JAR filename" }, { "type": "domain", "category": "External analysis", "to_ids": false, "value": "ne-rat.xyz", "comment": "Commodity RAT service (tooling origin); admin panel at web.ne-rat.xyz" }, { "type": "hostname", "category": "External analysis", "to_ids": false, "value": "web.ne-rat.xyz", "comment": "RAT service admin panel" } ] } } ``` ## The fix isn't more RPKI Three changes would have caught this at three different layers. ### Check your ROAs. Hetzner announcing a /16 with `maxLength 24` is exactly what let a forged-origin /24 pass validation here. A permissive `maxLength` authorises every sub-block you don't actually announce, and hands an attacker a valid slot to forge into. Set `maxLength` to the length you actually announce. ### Monitor your own prefixes. Alert on new more-specifics of your space and on unexpected AS adjacencies next to your origin. Those are the two signals GRIP caught and conventional MOAS tooling missed. ### Sign your updates and verify signatures on the receiving end. The one that would have stopped the damage here. Virtualizor has acknowledged its update clients didn't do this and says a code-signing mechanism is coming. A valid TLS certificate and a valid RPKI check are both worthless against a tampered package if nothing checks the package itself is authentic. --- ## Sources - [https://www.virtualizor.com/blog/security-incident-bgp-hijacking/](https://www.virtualizor.com/blog/security-incident-bgp-hijacking/?ref=sargeson.com.au) - [https://www.softaculous.com/blog/security-incident-bgp-hijacking-update/](https://www.softaculous.com/blog/security-incident-bgp-hijacking-update/?ref=sargeson.com.au) - [https://lowendtalk.com/discussion/220625/urgent-virtualizor-compromised-31st-aug](https://lowendtalk.com/discussion/220625/urgent-virtualizor-compromised-31st-aug?ref=sargeson.com.au) - [https://stat.ripe.net/data/routing-history/data.json?resource=162.55.0.0/16&starttime=2026-08-20T00:00:00](https://stat.ripe.net/data/routing-history/data.json?resource=162.55.0.0/16&starttime=2026-08-20T00:00:00&ref=sargeson.com.au) - [https://stat.ripe.net/data/bgp-updates/data.json?resource=162.55.80.0/24&starttime=2026-08-28T00:00:00&endtime=2026-08-31T04:00:00](https://stat.ripe.net/data/bgp-updates/data.json?resource=162.55.80.0/24&starttime=2026-08-28T00:00:00&endtime=2026-08-31T04:00:00&ref=sargeson.com.au) - [https://stat.ripe.net/data/looking-glass/data.json?resource=162.55.80.0/24](https://stat.ripe.net/data/looking-glass/data.json?resource=162.55.80.0/24&ref=sargeson.com.au) - [https://stat.ripe.net/data/rpki-validation/data.json?resource=AS24940&prefix=162.55.80.0/24](https://stat.ripe.net/data/rpki-validation/data.json?resource=AS24940&prefix=162.55.80.0/24&ref=sargeson.com.au) - [https://api.grip.inetintel.cc.gatech.edu/json/event/id/defcon-1787950500-24940](https://api.grip.inetintel.cc.gatech.edu/json/event/id/defcon-1787950500-24940?ref=sargeson.com.au) - [https://api.certspotter.com/v1/issuances?domain=virtualizor.com&include\_subdomains=true&expand=dns\_names&expand=issuer&expand=cert\_der](https://api.certspotter.com/v1/issuances?domain=virtualizor.com&include%5Fsubdomains=true&expand=dns%5Fnames&expand=issuer&expand=cert%5Fder&ref=sargeson.com.au) - [http://yr1.c.lencr.org/66.crl](http://yr1.c.lencr.org/66.crl?ref=sargeson.com.au) - [https://www.cyberkendra.com/2026/08/virtualizor-compromised-via-bgp-hijack.html](https://www.cyberkendra.com/2026/08/virtualizor-compromised-via-bgp-hijack.html?ref=sargeson.com.au) - [https://stat.ripe.net/data/as-overview/data.json?resource=AS62390](https://stat.ripe.net/data/as-overview/data.json?resource=AS62390&ref=sargeson.com.au) - [https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS62390](https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS62390&ref=sargeson.com.au)