- 2026年8月28日至30日期间，一个被 Virtualizor 使用的 Hetzner IP 地址段遭到 BGP 劫持并被重新路由——攻击者获得了有效的 TLS 证书，并借此分发了被篡改的更新。
- 受影响的是恰好在这段时间内检查更新的服务器。Virtualizor 无法给出确切名单，因此每台运行 Virtualizor 的服务器都应视为需要检查的对象。
- Prepaid-Host 不受影响：我们使用 Proxmox，而非 Virtualizor。对于你在我们这里的服务器，你无需采取任何行动。
发生了什么
从8月28日约 UTC 20:57 到8月30日约 UTC 06:10 之间，IP 地址段 162.55.80.0/24 遭到重新路由。该地址段属于 Hetzner，由 Virtualizor 用于其服务。该路由由 AS62390（NexonHost Srl）通过中转 AS6204（Zet.net / InterKVM Host Srl）进行宣告。合法的来源应为 AS24940，也就是 Hetzner 本身。因此流量并未到达 Virtualizor，而是流向了攻击者。
此次劫持分两波进行。第一波从8月28日晚间持续到8月29日约 UTC 08:50，此时 Hetzner 开始处理故障，重新路由降至零。大约十一个小时的平静期后，第二波紧随而至，从8月29日约 UTC 20:00 持续到8月30日 UTC 06:00。UTC 06:10 时，这条未经授权的路由被撤回。此后路由已恢复正常。
为什么没有人看到证书警告
这正是令人不安之处。谁掌控了一条 IP 路由，谁就掌控了证书颁发机构的自动域名验证。而这正是此次发生的情况：据 Virtualizor 称，Let's Encrypt 的验证同样经由这条被劫持的路径进行，攻击者因此为 Virtualizor 的域名获得了一张技术上完全合规的证书。
对受影响的服务器来说，一切看起来都很正常：HTTPS、有效证书、没有任何警告提示。“锁头图标是否显示”这种常规检查根本无法发现这次攻击。
随后，一个被篡改的更新包被分发了出去——发给了恰好在重新路由期间检查更新的那些安装实例。Virtualizor 表示受影响的只是少数服务器，而非广泛的用户群体，但无法给出一份可靠的名单：因为相关请求发往了攻击者，而不是厂商自己。因此官方给出的明确建议是，将每一台 Virtualizor 服务器都当作受影响对象来处理。
需要说明的是：Virtualizor 表示，截至目前尚未在公司旗下其他产品中发现被篡改的软件包，但调查仍在进行中。这明确不意味着 Softaculous 或 Webuzo 可以解除警报。
你在运行 Virtualizor？请按以下步骤逐一检查
检查以下文件是否存在：
test -e /etc/systemd/system/java-jre-update.service && echo BETROFFEN || echo sauber
如果该文件存在，说明你的服务器受到了影响。不要直接删除它。删除该文件会让你失去追查线索，同时攻击者设置的其他一切仍会原封不动地保留下来。请联系 Virtualizor 支持团队。
在主控面板（Master Panel）中重置所有 API 密钥，并将 API 访问限制在固定的 IP 地址范围内。
逐一检查已保存的 API 密钥和 SSH 密钥，移除任何你无法确认来源的密钥：
for f in /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys; do echo "== $f"; cat "$f" 2>/dev/null; done
不要只查看密钥，也要检查计划任务和对外连接。被植入的软件包会自行建立回连通道。
systemctl list-timers --all; crontab -l; ss -tupn state established
如果你在这段时间内登录过 Softaculous 的客户中心，请修改密码并检查账户活动记录。如果曾在那里输入过支付信息，还请额外核对信用卡账单。
Virtualizor 提供了一个检测脚本，并已宣布将发布包含时间线和技术分析的详细报告。上述手动检查步骤不能替代这些内容——它只是能更早派上用场。
Prepaid-Host 客户是否受影响？
我们的基础设施未受影响。我们的虚拟化基于 Proxmox，任何地方都没有使用 Virtualizor，前面提到的那个文件也不存在于我们的系统中。
当然，你完全可以在自己的独立服务器上自行运行 Virtualizor——那是你的机器。若是如此，本次事件对你的影响与其他任何运营者无异，上述检查清单同样适用于你的安装。需要协助排查时随时联系我们。
该从中吸取什么教训
现在很容易脱口而出一句“RPKI 本可以阻止这一切”。但事情没有这么简单。
我们自己的网络都通过 ROA 签名，并在 RPKI 校验中显示为有效。但被劫持的那个 Hetzner 地址段同样如此。签名只有在路径上的网络切实执行来源验证、并真正丢弃无效宣告时才有效。只要有一个中转网络不这么做，再好的签名也无济于事。
第二个教训适用于每一个使用软件自动更新的人：一个仅依赖 TLS 和 DNS 的更新渠道，在路由攻击面前毫无还手之力——因为这两个环节恰恰都要经过那条被劫持的网络。真正能起作用的是经过签名的软件包，客户端凭借固定内置的密钥来验证签名。这样一来，文件究竟来自哪台服务器就无关紧要了。
信息来源
- Virtualizor，Security Incident – BGP Hijacking，2026年8月31日——官方声明，包含时间线和检查步骤
- LowEndTalk，URGENT: Virtualizor Compromised (31st Aug)——来自运营者社区的最早报告
- RIPE NCC，RIPEstat——路由数据及相关 AS 号码持有者信息；我们自己也在该平台核实了我们网络的 RPKI 状态
_6a4f6e96d67aa.png)