BGP Hijack Poisons Virtualizor Updates via Softaculous: Root Compromise Detection and Remediation Guide

Virtualizor has confirmed that attackers used a Border Gateway Protocol (BGP) hijack to divert traffic destined for Softaculous update infrastructure. That diverted traffic was then used to push a malicious Virtualizor update package to some installations. This was not a vulnerability in Virtualizor's code — it was a compromise of the trust relationship between the update client and the update server, executed at the routing layer. One hosting provider that publicly checked its fleet reported 5 of 34 Virtualizor hypervisors sustained root-level compromise. That is a ~15% hit rate on a sampled population, which tells us this was opportunistic at scale, not a targeted one-off.

The incident window began approximately August 28 at 20:57 (2026). If you operate Virtualizor hypervisors — and if you run a hosting business, you almost certainly do — treat every node that pulled updates during and after that window as potentially compromised until proven otherwise.

Why This Matters Beyond Virtualizor

BGP hijacking as a malware delivery mechanism is a mature nation-state and criminal technique (MITRE ATT&CK T1557 — Adversary-in-the-Middle, and effectively T1195.001 — Supply Chain Compromise: Software Supply Chain). Routing is the soft underbelly of the update ecosystem: most update clients authenticate the server by DNS name and TLS, but if an attacker can reroute the prefix and present a certificate (or the client doesn't validate one properly), the client has no way to know it's talking to an impostor. This incident is a live demonstration that hypervisor management planes — which hold the keys to every guest VM on the box — are a high-value, under-monitored target for exactly this attack class.

Technical Analysis

Affected Products and Platforms

Virtualizor hypervisor panels (KVM/Xen/OpenVZ/LXC nodes) that fetched updates during the incident window beginning ~August 28, 2026 20:57 UTC
Update traffic destined for Softaculous update/distribution infrastructure
Predominantly Linux hypervisor hosts (CentOS/AlmaLinux/Rocky/Ubuntu families are the common Virtualizor bases)
Downstream impact: every guest VPS/container hosted on a compromised hypervisor must be considered exposed — root on the hypervisor means access to guest disks, memory, and network traffic

Attack Chain (Defender's View)

Prefix hijack: The attackers announced (or caused to be announced) illegitimate BGP routes for IP space used by Softaculous update services, causing upstream networks to steer update traffic toward attacker-controlled infrastructure. Because the default BGP trust model has no built-in origin validation (RPKI adoption remains incomplete in 2026), the hijacked announcements propagated.
Traffic interception: Virtualizor nodes performing routine update checks were routed to the malicious infrastructure instead of legitimate Softaculous mirrors.
Malicious package delivery: The attacker served a trojanized Virtualizor update package. The node, believing it was talking to the legitimate update server, downloaded and installed it.
Root execution: Virtualizor updates run as root (the panel manages hypervisor functions). The malicious package therefore executed with full privileges — no privilege escalation required.
Persistence establishment: Per the reporting, the payload establishes persistent root access. Expect standard Linux rootkit-style persistence: systemd units, cron entries, LD_PRELOAD hooks, modified PAM configuration, planted SSH authorized_keys, or kernel-level components.

Exploitation Status

Confirmed active exploitation in the wild. This is not theoretical — a hosting provider has already disclosed root-level compromise on 5 of 34 checked hypervisors.
No CVE identifier has been published for this incident (it is an infrastructure/routing compromise, not a software flaw). No CVE is claimed in this article.
Monitor CISA KEV and the Virtualizor/Softaculous vendor channels for follow-on advisories and IoC publication.

Detection & Response

Your hunting priorities, in order: (1) identify which nodes pulled updates during the incident window, (2) look for persistence artifacts created around that window, (3) identify outbound connections from hypervisors to update infrastructure resolving to unusual IPs/ASNs during the window, (4) assume lateral movement into guest VMs on any confirmed-compromised node.

Sigma Rules

These rules target the persistence and execution behaviors typical of a root-delivered malicious package. Deploy against Linux auditd/sysmon-for-linux telemetry on hypervisor nodes.

YAML

---
title: Suspicious Systemd Unit Created During Virtualizor Update Window
id: 1c7f2a44-8b3d-4e51-9c62-7a9d0e1f2b3c
status: experimental
description: Detects creation of new systemd service or timer unit files, a common persistence mechanism for root-level payloads delivered via trojanized packages. Correlate hits against the Virtualizor BGP hijack incident window beginning 2026-08-28 20:57 UTC.
references:
  - https://attack.mitre.org/techniques/T1543/002/
  - https://thehackernews.com/2026/09/bgp-hijack-delivers-malicious.html
author: Security Arsenal
date: 2026/09/02
tags:
  - attack.persistence
  - attack.t1543.002
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|startswith:
      - '/etc/systemd/system/'
      - '/usr/lib/systemd/system/'
      - '/lib/systemd/system/'
      - '/etc/systemd/system/multi-user.target.wants/'
    TargetFilename|endswith:
      - '.service'
      - '.timer'
  filter_known_package_ops:
    Image|endswith:
      - '/usr/bin/dpkg'
      - '/usr/bin/rpm'
      - '/usr/bin/apt'
      - '/usr/bin/dnf'
      - '/usr/bin/yum'
  condition: selection and not filter_known_package_ops
falsepositives:
  - Legitimate software installation writing unit files via non-package-manager installers
  - Configuration management (Ansible/Puppet/Chef) deploying services
level: high
---
title: Cron Persistence Artifact Created on Virtualizor Hypervisor
id: 2d8e3b55-9c4e-5f62-0d73-8b0e1f2a3c4d
status: experimental
description: Detects writes to cron spool and cron.d directories, a frequent persistence location for malicious packages executing as root. High-signal on hypervisor hosts where cron changes are rare outside of maintenance windows.
references:
  - https://attack.mitre.org/techniques/T1053/003/
  - https://thehackernews.com/2026/09/bgp-hijack-delivers-malicious.html
author: Security Arsenal
date: 2026/09/02
tags:
  - attack.persistence
  - attack.t1053.003
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename|startswith:
      - '/etc/cron.d/'
      - '/etc/cron.daily/'
      - '/etc/cron.hourly/'
      - '/var/spool/cron/'
  condition: selection
falsepositives:
  - Administrative scheduling of backup or monitoring jobs
  - Package installation adding cron entries
level: medium
---
title: Root Authorized Keys Modification on Hypervisor Host
id: 3e9f4c66-0d5f-6073-1e84-9c1f2a3b4d5e
status: experimental
description: Detects modification of the root account SSH authorized_keys file. On Virtualizor hypervisors where root SSH is typically disabled or tightly controlled, any change to this file following the update incident window is a strong compromise indicator.
references:
  - https://attack.mitre.org/techniques/T1098/004/
  - https://thehackernews.com/2026/09/bgp-hijack-delivers-malicious.html
author: Security Arsenal
date: 2026/09/02
tags:
  - attack.persistence
  - attack.t1098.004
logsource:
  category: file_event
  product: linux
detection:
  selection:
    TargetFilename: '/root/.ssh/authorized_keys'
  condition: selection
falsepositives:
  - Break-glass administrative key rotation (should be rare and change-controlled)
level: critical

KQL Hunting Queries (Microsoft Sentinel)

Assuming your hypervisors forward syslog/auditd into Sentinel (via the Syslog/CEF agent), these queries hunt the persistence window and anomalous update-server contact.

KQL — Microsoft Sentinel / Defender

// 1. New systemd services or cron entries created during/after the incident window
let IncidentStart = datetime(2026-08-28T20:57:00Z);
Syslog
| where TimeGenerated >= IncidentStart
| where SyslogMessage has_any ("systemd", "cron", "crontab")
| where SyslogMessage has_any ("Created symlink", "Reloading", "new unit", "(root) CMD", "REPLACE")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated asc;

// 2. SSH key and root account artifact changes surfaced via syslog/auth logs
let IncidentStart = datetime(2026-08-28T20:57:00Z);
Syslog
| where TimeGenerated >= IncidentStart
| where Facility == "auth" or ProcessName =~ "sshd"
| where SyslogMessage has_any ("authorized_keys", "Accepted publickey for root", "session opened for user root")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP
| order by TimeGenerated asc;

// 3. Hypervisors contacting update infrastructure — baseline review of outbound destinations
// Use this to identify update connections to unexpected IPs during the hijack window.
let IncidentStart = datetime(2026-08-28T20:57:00Z);
let IncidentEnd = datetime(2026-09-01T00:00:00Z);  // extend per vendor disclosure
CommonSecurityLog
| where TimeGenerated between (IncidentStart .. IncidentEnd)
| where DestinationPort in (80, 443)
| where DeviceAction !in ("deny", "blocked")
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SourceHostName, DestinationIP, DestinationHostName
| order by ConnectionCount asc  // rare destinations rise to the top

Velociraptor VQL Hunt

Deploy this artifact across hypervisor nodes to collect the persistence surface: recently created/modified systemd units, cron artifacts, SSH key material, and unexpected listeners. Baseline results against a known-good node — any unit present on compromised nodes but absent from gold images is a lead.

VQL — Velociraptor

-- Hunt: Virtualizor malicious update persistence surface
-- Collects systemd units, cron files, and root SSH artifacts modified around the incident window
LET window_start <= "2026-08-28T20:00:00Z"

LET systemd_files = SELECT FullPath, Mtime, Size
FROM glob(globs=['/etc/systemd/system/**/*.service',
                 '/etc/systemd/system/**/*.timer',
                 '/usr/lib/systemd/system/*.service'])
WHERE Mtime > window_start

LET cron_files = SELECT FullPath, Mtime, Size
FROM glob(globs=['/etc/cron.d/*', '/var/spool/cron/*', '/etc/cron.daily/*'])
WHERE Mtime > window_start

LET ssh_artifacts = SELECT FullPath, Mtime, Size
FROM glob(globs=['/root/.ssh/authorized_keys', '/home/*/.ssh/authorized_keys'])
WHERE Mtime > window_start

SELECT "systemd" AS Category, FullPath, Mtime, Size FROM systemd_files
UNION ALL
SELECT "cron" AS Category, FullPath, Mtime, Size FROM cron_files
UNION ALL
SELECT "ssh_keys" AS Category, FullPath, Mtime, Size FROM ssh_artifacts

VQL — Velociraptor

-- Hunt: unexpected listening services and outbound connections from hypervisors
SELECT Pid, Name, Path, Address, Port, Status
FROM netstat()
WHERE Status =~ 'LISTEN'
  AND NOT Address =~ '^127\\.'
  AND NOT Port in (22, 4081, 4082, 4083, 4084, 4085)  // SSH + standard Virtualizor ports — tune to your baseline

Remediation and Verification Script

Run this on every Virtualizor node. It collects integrity and persistence evidence, and validates that update resolution is not currently being diverted. It is a triage script, not a cleaner — confirmed compromised hypervisors require rebuild, not scrubbing.

Bash / Shell

#!/bin/bash
# Security Arsenal - Virtualizor BGP Hijack Incident Triage
# Run as root. Read-only collection plus routing/DNS sanity checks.

OUT="/root/virt_triage_$(hostname)_$(date +%Y%m%d%H%M).txt"
exec > >(tee -a "$OUT") 2>&1

echo "=== [1] DNS resolution sanity for update infrastructure ==="
# Compare resolution across two independent resolvers. Divergence = possible active interception.
for host in files.virtualizor.com api.softaculous.com; do
  echo "--- $host via system resolver:"
  getent hosts "$host" || dig +short "$host"
  echo "--- $host via 1.1.1.1:"
  dig +short "$host" @1.1.1.1 2>/dev/null
  echo "--- $host via 9.9.9.9:"
  dig +short "$host" @9.9.9.9 2>/dev/null
done

echo "=== [2] systemd units modified since incident window (2026-08-28) ==="
find /etc/systemd/system /usr/lib/systemd/system /lib/systemd/system \
  \( -name '*.service' -o -name '*.timer' \) -newermt '2026-08-28' -ls 2>/dev/null

echo "=== [3] cron artifacts modified since incident window ==="
find /etc/cron.d /etc/cron.daily /etc/cron.hourly /var/spool/cron \
  -newermt '2026-08-28' -ls 2>/dev/null

echo "=== [4] SSH authorized_keys changes ==="
find /root/.ssh /home/*/.ssh -name 'authorized_keys' -newermt '2026-08-28' -ls 2>/dev/null
stat /root/.ssh/authorized_keys 2>/dev/null

echo "=== [5] Recently created users / root-equivalent accounts ==="
awk -F: '($3 == 0) {print "UID0:", $1}' /etc/passwd
awk -F: -v d="$(date -d '2026-08-28' +%s)" '{print}' /etc/passwd | tail -20

echo "=== [6] LD_PRELOAD / ld.so.preload rootkit indicator ==="
ls -la /etc/ld.so.preload 2>/dev/null && cat /etc/ld.so.preload
echo "LD_PRELOAD env in service units:"
grep -rl 'LD_PRELOAD' /etc/systemd/system/ 2>/dev/null

echo "=== [7] Recent root logins ==="
last -30 root 2>/dev/null
grep -E 'Accepted (password|publickey) for root' /var/log/secure /var/log/auth.log 2>/dev/null | tail -30

echo "=== [8] Non-standard listeners ==="
ss -tlnp 2>/dev/null | grep -vE ':(22|4081|4082|4083|4084|4085)\b'

echo "=== [9] Virtualizor package file integrity spot-check ==="
# Flag any Virtualizor panel files modified during the incident window
find /usr/local/virtualizor -newermt '2026-08-28' ! -newermt '2026-09-10' -type f 2>/dev/null | head -100

echo "=== [10] Package manager verification of installed RPM/DEB files ==="
if command -v rpm >/dev/null; then rpm -Va 2>/dev/null | grep -E '^..5' | head -50; fi
if command -v debsums >/dev/null; then debsums -c 2>/dev/null | head -50; fi

echo "=== Triage complete. Evidence bundle: $OUT ==="
echo "If sections 2-7 show unexpected artifacts: ISOLATE the node, do NOT clean in place. Plan rebuild and guest-VM credential rotation."

Remediation

Isolate first, ask questions second. Any hypervisor that pulled updates on or after August 28, 2026 ~20:57 UTC should be treated as suspect. If your triage surfaces unexpected persistence artifacts (sections 2–7 above), network-isolate the node immediately. Root-level persistence delivered by a trojanized package cannot be reliably removed in place — attacker dwell time and unknown secondary payloads make in-place cleaning a false economy.
Rebuild compromised hypervisors from known-good media. Reinstall the OS and Virtualizor from verified sources. Restore guest VMs from backups that predate the incident window where feasible, and assess each guest for compromise indicators — the attacker had root on the hypervisor, which means full access to guest virtual disks.
Rotate all credentials with a path through the hypervisor. This includes Virtualizor admin credentials, root SSH keys, API keys, and — critically — credentials of guest VMs on confirmed-compromised nodes (the attacker could have harvested them from disk or memory). Assume downstream compromise and notify affected customers per your contractual and regulatory obligations.
Verify update integrity going forward. Follow the official Virtualizor/Softaculous advisory (monitor https://www.virtualizor.com/blog/ and Softaculous channels) for published package hashes or signatures of the legitimate post-incident release. Validate packages against vendor-published checksums/signatures before installation where the vendor provides them.
Pin and monitor update traffic. Log all outbound connections from hypervisor management interfaces. Alert on update-server DNS answers resolving to IPs outside the vendor's documented ranges or announced by unexpected ASNs. Where your firewall supports it, restrict hypervisor egress to required update destinations only.
Engage your upstream/transit providers on routing security. Ask whether they implement RPKI-based Route Origin Validation (ROV) and whether they filter invalid announcements. If you announce your own prefixes, publish ROAs and consider BGP monitoring (e.g., BGPStream, Cloudflare Radar, or a commercial BGP alerting service) so your traffic paths are watched the way Softaculous's should have been.
Implement update-window change detection. Deploy file integrity monitoring (AIDE, Wazuh FIM, or equivalent) on hypervisor OS and panel directories with alerts on any modification outside scheduled maintenance windows. In this incident, FIM would have caught the trojanized package the moment it wrote to disk.
Segment the management plane. Virtualizor panels and hypervisor management interfaces should sit on a dedicated management VLAN, unreachable from guest VMs and from the internet except via jump host with MFA. Root-level compromise of one node should never become a skeleton key to your fleet.

The uncomfortable lesson here: your patch pipeline is only as trustworthy as the routing between you and the vendor. Supply-chain defense in 2026 has to extend below Layer 7 — into DNS validation, routing telemetry, and egress control — because the attackers are already there.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub