Wiz CTO警告：互联网老旧代码迎来“漏洞末日”

PHP最近爆出的两个高危漏洞，让大量依赖这一开源语言的网站不得不紧急下线修复。尽管这场风波在信息流里逐渐退潮，但清理工作远未结束。Wiz 首席技术官在近期表态中提出了一个更宏观的判断：互联网长期积累的老旧代码，正在把整个行业推向一场“漏洞末日”（Vulnpocalypse）。

一次PHP惊魂暴露的结构性问题

据原始报道，这两个关键漏洞出现在支撑约 70% 网站的开源语言中。对很多组织而言，这不是一次普通的补丁更新，而是需要临时关停站点、等待修复的紧急事件。研究者发现漏洞后的处置过程，也暴露出一个尴尬的现实：互联网的底层依赖高度集中，少数开源项目承载了远超其维护能力的流量与信任。

这种集中性意味着，单个语言层面的缺陷可以迅速演变为全行业的应急事件。Wiz CTO 的警告正是从这个角度出发——PHP 的这次风波不是孤例，而是一个可复制的模板，未来会以不同形式在更多老旧代码栈上重演。

PHP 是一种开源的服务器端脚本语言，由 Rasmus Lerdorf 于 1994 年创建，最初用于维护个人主页，后经多次重写演变为通用编程语言。其设计目标是快速开发动态网页，语法宽松、上手门槛低，因而成为早期互联网建站的主流选择。大量 CMS（如 WordPress、Drupal、Joomla）和电商框架（如 WooCommerce、Magento）均以 PHP 为基座，导致其部署面覆盖全球约七成网站。然而 PHP 的版本迭代较快，旧版本往往在官方停止安全支持后仍被大量站点沿用，形成长期暴露面。这种“低门槛、高存量、慢升级”的组合，正是单个语言层面漏洞能够演变为全行业应急事件的技术土壤。

为什么“漏洞末日”不是危言耸听

老旧代码的问题不在于“老”，而在于它往往同时具备三个特征：被广泛依赖、缺乏持续维护、以及难以被替换。很多系统在多年前上线后一直稳定运行，团队早已更替，文档缺失，升级路径模糊。当安全研究者开始集中审视这些代码时，漏洞的发现速度可能超过修复速度。

Wiz CTO 使用的“Vulnpocalypse”一词，指向的正是这种节奏失衡。防御方需要逐一排查、测试、部署，而攻击面和漏洞披露是同时从多个方向涌来的。对于以开源语言为基座的互联网来说，这种不对称会持续放大风险。

“Vulnpocalypse”是 vulnerability（漏洞）与 apocalypse（末日）的合成词，属于安全行业常用的夸张修辞，用于描述漏洞集中爆发、防御方难以招架的局面。与之概念相近的还有“patch apocalypse”（补丁末日）和“dependency hell”（依赖地狱）。这类术语并非严谨的学术定义，而是用来传递节奏感：漏洞披露速度超过组织的修复吞吐量。在开源生态中，这一节奏失衡尤其明显，因为漏洞信息一旦公开，攻击者与防御者几乎同时获得线索，而防御方还需完成排查、测试、变更审批和部署等漫长流程，时间差便构成了实际风险窗口。

对企业和开发团队的现实含义

从这次 PHP 事件的处理方式可以看出，临时下线虽然能止损，但代价高昂，且不可持续。更务实的做法是把老旧依赖纳入常态化的资产盘点：清楚自己用了什么、哪些版本已无人维护、替换或隔离的成本有多高。安全团队与工程团队需要就“哪些系统可以承受停机修复”提前达成共识，而不是在漏洞公开后才临时决策。

开源生态本身也需要更健康的维护模式。广泛使用的项目如果长期依赖少数维护者，风险就会被系统性地积累下来。Wiz CTO 的警告，本质上是在提醒行业：漏洞的集中爆发不是意外，而是维护责任长期错配的结果。

软件物料清单（SBOM）是指对软件产品中各组件、依赖及其版本的机器可读清单，类似制造业的物料清单。美国在 2021 年 Log4Shell 事件后推动 SBOM 成为供应链安全的基础实践，其核心价值在于让组织能够快速回答“我是否使用了受影响的组件、哪个版本、在哪些系统中”。对于老旧代码栈，SBOM 可以把“不清楚自己用了什么”的模糊状态转化为可查询的资产台账，从而支撑依赖维护状态评估、隔离决策和替换排期。缺乏 SBOM 时，一次漏洞披露往往需要数天甚至数周的人工排查，这正是漏洞末日叙事中防御方节奏落后的关键原因之一。

常见问题

“Vulnpocalypse”具体指什么？ 这是 Wiz CTO 用来描述互联网老旧代码集中爆发安全漏洞的说法，强调漏洞发现与修复之间的节奏失衡。

PHP 漏洞事件和这个警告有什么关系？ PHP 支撑约 70% 的网站，两个关键漏洞导致部分站点下线修复，被视为老旧代码风险的现实案例。

团队应该优先做什么？ 盘点老旧依赖、评估维护状态与替换成本，并为可能需要停机的系统提前准备应急方案。