一次BGP劫持，为什么“HTTPS正常”也失守？（事件复盘篇）
——Softaculous / Virtualizor 供应链事件给CIO的深层警示

攻击者没有必要攻破你的服务器。
只要控制你信任服务器的方式，同样可以进入你的系统。

2026年8月31日，Softaculous披露了一起非常值得企业IT管理者研究的安全事件。

从8月28日20:57 UTC 到8月30日约06:10 UTC，其部署在Hetzner网络中的 162.55.80.0/24 地址段遭到未经授权的BGP路由宣告。原本应该访问Softaculous基础设施的互联网流量，被部分导向攻击者控制的服务器。

如果这只是一次“流量走错路”，它或许只是一场网络故障。真正危险的是，攻击者进一步获得了技术上有效的TLS证书，最终让少量Virtualizor服务器在看不到明显HTTPS证书异常的情况下，接收到了恶意软件更新。

攻击者没有攻破服务器，而是控制了“你信任谁”。

一、33小时里，到底发生了什么？

BGP承担着互联网不同自治系统之间“告诉别人流量应该往哪里走”的职责。

此次事件中，AS62390 开始未经授权宣告 162.55.80.0/24，并通过 AS6204 传播。由于这个 /24 比Hetzner正常宣告所覆盖的 162.55.0.0/16 更加具体，根据互联网常见的最长前缀匹配机制，接受该路由的网络会优先把流量送向这个更具体的路径。

事件并非持续稳定劫持，而是形成两个主要波段。第一阶段从8月28日约20:57持续至29日08:50；随后出现约11小时的近乎正常窗口；第二阶段又从29日晚持续至30日约06:10。

368个观察Peer曾看到劫持路由，峰值约72%观察点被导向异常路径。注意：这是路由观察样本，不是全球流量。

Virtualizor根据RIPE RIS 数据重建后称，368个观察Peer都曾在事件中的某个时间点看到这条劫持路由；活跃阶段的峰值约相当于全部368个观察点中的72%左右被导向异常路径。

需要特别注意：这个72%反映的是路由拓扑观察样本，并不是“72%的全球互联网流量被劫持”。这是理解事故规模时非常重要的专业边界。

而真正把事故级别推高的，是后面两步：

1. 获取 TLS 证书：攻击者控制了目标流量之后，由于证书机构的域名所有权验证流量同样经过被劫持路径，因此攻击者能够获得 Softaculous 相关域名的有效 TLS 证书。

2. 伪造更新包：随后，Virtualizor 更新客户端在当时尚未对下载的软件包进行独立的密码学签名验证。于是，一旦更新请求恰好发生在被劫持窗口里，“路由正确性”和“HTTPS 证书”两道信任同时失守后，恶意软件包就可能被客户端当成正常更新执行。

官方确认有少量Virtualizor安装受到影响，但由于恶意响应发生在攻击者服务器上，厂商无法通过自身日志给出绝对完整的受影响主机名单。

这也是整场事件最值得CIO注意的一句话：攻击者没有必要攻破你的服务器，只要能够控制你信任服务器的方式，同样可以进入你的系统。

二、为什么HTTPS没拦住？

很多人以为：HTTPS正常=安全；证书有效=服务可信；更新成功=更新包正确。这次事件证明：这些假设都不成立。

HTTPS正常 ≠ 更新可信。

TLS保护的是传输通道，不等于证明“你拿到的软件就是厂商真正发布的软件”。当路由被劫持，同时证书验证过程又受网络路径影响时，“浏览器显示小锁”并不能替代软件包自身的真实性验证。

NIST关于Code Signing 的指导明确指出，数字签名能够提供两项HTTPS无法完全替代的能力：

1. 完整性——软件是否被修改；

2. 来源认证——到底是谁签署并发布了软件。

因此，企业级软件更新至少应该形成：

TLS传输保护+软件包数字签名+发布密钥保护+客户端强制验签+ Hash/Manifest 校验+版本/回滚保护。

即使DNS、CDN、BGP甚至TLS中的某一环出现问题，只要攻击者拿不到供应商真正的代码签名密钥，恶意更新仍然应该在最终执行前被拒绝。这就是所谓：把安全从“路径可信”升级为“内容本身可信”。

三、真正的危机，才刚刚开始

如果复盘只得出“应该加强BGP安全”，那么企业只吸取了大约三分之一的教训。

从ITIL V5、ISO/IEC 20000、IT4IT、SRE、BCM、供应链安全和Zero Trust 角度看，这次事件的本质不是某一个设备、某一个工程师或者某一个供应商出了问题，而是多个安全控制原本存在，却没有形成真正的Defense in Depth——纵深防御。

没人对整条信任链负责。 这是这起事件暴露出的最深层次问题。网络团队懂BGP，安全团队懂攻击检测，应用团队懂软件更新，采购团队管供应商，BCM团队负责业务连续性——每个团队都可能“做对了自己的事情”，但事故依然发生。

HTTPS正常不代表服务可信，证书有效不代表软件可信。如果企业只关注自己的数据中心和云账户，而忽略了互联网路由、云厂商、托管商、CDN、CA、开源社区、软件供应商和更新平台，那么下一次供应链事件，可能依然无法幸免。

下一篇，我们将从治理、流程、供应商管理和监控体系等维度，详细拆解这起事件给CIO带来的深层警示，并给出0-90天的具体整改清单。