PHP双漏洞震动全球：远程代码执行漏洞详解

PHP，这个支撑着从WordPress到Wikipedia无数网站的后端语言，最近因两个远程代码执行漏洞被推上风口浪尖。Computerphile 在一期视频中详细拆解了漏洞原理、真实演示以及发布环节的混乱，本文基于该视频内容进行梳理与延伸分析。

两个漏洞究竟是怎么回事

据 Computerphile 介绍，PHP 的工作机制依赖一系列 worker 线程处理 HTTP 请求。每个 worker 持有跨请求存在的全局状态，包括错误状态、使用中的对象和扩展信息；而每个请求本身是临时性的。当请求被处理或销毁时，指向它的引用本应被正确清理。

第一个漏洞的关键在于：某些异常路径下，这些引用没有被完全重置，仍然指向已经销毁的旧请求。攻击者通过精心构造多个请求，可能让服务器执行自己注入的代码，而非网站作者预期的代码。

第二个漏洞与 C 语言中的 longjmp（长跳转）机制有关。PHP 在内存不足等错误场景下使用 longjmp 做错误处理，如果跳转落点出错、状态未正确重置，同样可能被利用来执行任意代码。

两个漏洞的共同后果是：攻击者可以从自己的电脑上，向目标网站发送请求并在其服务器上运行代码。这意味着数据窃取、将服务器作为跳板攻击他人等恶意操作都成为可能。

PHP 的 worker 线程模型是其高效处理并发请求的核心：每个 PHP-FPM 进程维持一组 worker，每个 worker 独立处理请求，并通过全局变量（如 PG(error_handling)、EG(active_op_array) 以及扩展注册的资源）在请求间复用以避免重复初始化。请求结束时，PHP 会执行 php_request_shutdown 清理这些状态，但清理逻辑依赖精确的引用计数和指针重置。若某个异常分支（如扩展抛出的错误或内存分配失败）跳过了某一步，就会留下悬垂指针（dangling pointer）。攻击者利用堆喷射（heap spraying）和精确的请求时序控制，可让后续请求在已释放的内存区域上重建可控数据，从而劫持控制流。类似漏洞在 PHP 历史上并非首次，但此次影响跨度长达 14 年，凸显了长期存活的全局状态在复杂错误路径下的脆弱性。

演示：真的能拿到服务器权限

视频中，主讲人借助一个公开的 Python 漏洞利用脚本进行了本地演示。他先启动一个只返回“ok”的极简 PHP 服务器，然后运行脚本。脚本执行完毕后，在指定目录下生成了一个文件，其中记录了执行命令 id 的结果——用户名为 www-data，即典型的 Web 服务器运行账户。

这个演示明确了一件事：漏洞真实存在，利用脚本也确实有效，绝非噱头。

影响范围为何如此之大

漏洞的严重性不仅在于可远程执行代码，更在于它的时间跨度。据视频所述，该问题存在于大约 14 年间的 PHP 版本中，从 PHP 5 一直到 PHP 8.5 均受影响。考虑到 PHP 在全球网站后端的普及程度，几乎所有使用 WordPress 的站点都处在风险之中。

这也解释了为何英国 NCSC 等机构会发出措辞强硬的敦促：必须打补丁，若无法及时修补，应将网站下线直至完成修复。主讲人表示，这种级别的官方表态并不常见。

发布环节的混乱与负责任披露

按照惯例，漏洞应先通过负责任披露流程通知开发者，验证并制作补丁，再协调下游发行版，最后在公布漏洞的同时提供修复方案。但这次流程被意外打乱：有人在不知情的情况下将细节发到了 Hacker News，另有一段漏洞利用视频提前流出，导致整个发布被迫提前。

视频中还提到一个细节：PHP 团队在 2024 年就发现了其中一个漏洞，并讨论过是否修复，但当时既无法确认利用方式，也找不到不引入其他问题的修复方案，于是搁置了。主讲人认为这可能是错误决策，但也强调应看到开源团队在有限人力下取得的成果。

关于漏洞是否由大语言模型辅助发现，主讲人提出了一种推测：PHP 团队当年的公开讨论可能已被模型训练数据吸收，而部分 AI 公司正投入大量资源用模型挖掘漏洞。不过他明确表示，目前无法确认模型是否独立发现该漏洞，需要进一步检查才能下结论。

负责任披露（Responsible Disclosure）是安全社区广泛采纳的协作规范，通常包括：发现者私下联系厂商、给予 90 天修复窗口、双方协调公开时间。其核心目标是让用户在漏洞公开前获得补丁，避免“零日”攻击窗口。然而在实践中，这一流程常因信息泄露、多方协调困难或厂商响应迟缓而被打乱。本次事件中，Hacker News 的提前曝光和利用视频的流出直接压缩了 PHP 团队与下游发行版（如 Debian、Ubuntu、Red Hat）同步发布补丁的时间。这种“被迫提前公开”被称为“提前披露”（premature disclosure），往往导致补丁覆盖率不足、攻击者抢跑。历史上 OpenSSL 的 Heartbleed、Apache Log4j 的 Log4Shell 都曾面临类似困境，说明协调披露在高度中心化的开源生态中仍是未完全解决的难题。

为什么没有出现大规模攻击

令人意外的是，漏洞公开后并未出现预期中的大规模脚本小子攻击。主讲人分析，原因在于利用门槛并不低。

PHP 默认有 150 个 worker 线程，请求会被随机分配。攻击者必须让其余 149 个线程忙于无关任务，才能集中攻击剩余那一个。此外，还需要掌握目标运行的 PHP 版本、操作系统、甚至编译时使用的 C 编译器等信息。任何一个外部请求抢先到达那个空闲线程，攻击状态就会被破坏。因此，在实际生产环境中利用远比在本地 Docker 容器中困难。

主讲人还抛出一个耐人寻味的假设：如果恶意行为者先把后门代码植入 PHP，再策划这样一场“全球紧急打补丁”的事件，是否反而能借更新之机把恶意代码铺开？他强调这只是脑洞，并不认为真的发生了，但值得警惕。

PHP-FPM 默认的 pm.max_children 为 150，请求由内核或 FPM 调度器分配给空闲 worker，分配策略并不保证请求落在特定 worker 上。要利用该漏洞，攻击者需要确保恶意请求由那个持有“脏”全局状态的 worker 处理，同时阻止其他请求抢占它。常见手法是通过发送大量慢请求（slowloris 式）占满其余 worker，再精确发送恶意请求。但这一过程对网络延迟、服务器负载和时序极为敏感，且不同 PHP 版本、操作系统（glibc 版本影响堆布局）、编译器（GCC 与 Clang 的栈布局差异）都会改变内存布局，导致利用脚本高度依赖目标环境信息。此外，现代 Web 服务器常在前端部署 WAF 或反向代理，可能提前拦截异常请求模式。因此，尽管漏洞理论危害巨大，实际武器化门槛远高于本地实验环境，这也是未出现大规模蠕虫式攻击的主要原因。

给开发者的提醒

这次事件再次说明，依赖广泛的开源基础设施一旦出现远程代码执行漏洞，影响面会呈指数级放大。对网站管理者而言，及时跟进补丁、在无法修复时果断下线，仍是当前最有效的应对手段。而对于开源维护团队，如何在有限资源下平衡漏洞修复与兼容性风险，也将是一个长期存在的难题。