PHP 与 Node.js：2026 年 10 月的安全漏洞
2026 年 10 月 21 日公布的 PHP 与 Node.js 漏洞：CVE、修复版本，以及经过验证的更新方法，帮助你稳妥地保护网站和应用。
2026 年 10 月 21 日，我们检查了分布在容器、Node.js 环境和 PHP 应用中的数百个服务，并在当天更新了所有暴露在外的服务。随后，我们核实了实际运行中的进程，在应用环境的隔离副本上跑完了数千个自动化测试，并持续监控生产环境的端点，直到它们只返回正确的 HTTP 响应。最费劲的部分，是在替换运行时的同时，保证应用、数据库、发票生成和各种定制功能照常工作。
促使我们动手的是同一天发布的两份独立公告：PHP 的严重漏洞，以及 Node.js 的高危安全更新。它们涉及的是运行应用的软件本身。对企业来说，这意味着问题可能出在网站或业务系统的底层，即使为项目编写的代码一行都没改。
以下是截至 2026 年 10 月 21 日 核实的情况。文中列出的版本是修复这些公告所述问题的版本；如果更新是在之后进行的，还需要核对后续发布的安全版本。
10 月 26 日更新：公告发布前的攻击尝试
Amazon Threat Intelligence 于 10 月 17 日在其 MadPot 传感器中检测到一次 PHP2Shell 利用尝试，比 10 月 21 日的公开披露早了四天。这份于 10 月 21 日发布的研究还指出，在禁运期结束前，已有来自多个基础设施的尝试。AWS 说明技术分析仍在进行中，目前无法确定这些尝试在真实系统上是否会成功。
这改变了排查需要覆盖的时间范围：对于暴露在外的服务，AWS 建议至少从 10 月 17 日 开始检查日志、异常的进程执行和文件变更。安装补丁和排查此前是否已被入侵，是两项不同的检查。 10 月 21 日完成的更新，本身并不能证明系统在此前几天是干净的。
PHP 漏洞：CVE-2026-109618 与 CVE-2026-109619
PHP 官方公告 描述了两个可能导致无需认证的远程代码执行的漏洞。所谓 RCE，实际上就是攻击者可以通过一个可远程触达的漏洞，在系统上执行代码。网站有登录页面并不能消除这类问题，因为它可能在应用校验凭据之前就已经发生。
CVE-2026-109618 涉及内存耗尽时的处理：请求的部分内部数据可能只被部分初始化，随后在清理阶段被当作有效数据处理。在 Apache 加 mod_php 上演示的案例，可以在应用代码执行之前就被触发。官方分析认为 PHP-FPM 同样受影响，只是攻击路径不同，而且针对这一具体漏洞，尚无完整的 FPM 利用演示。
CVE-2026-109619 则涉及进程在上一个请求的内存被释放后仍可能保留的内部状态。后续的请求可能访问到这些已经失效的引用。触发条件取决于 worker 的行为和可触达的操作：把每个安装都说成已被入侵是不对的，但在没有修复的情况下认为它安全，同样不对。
对网站运营者来说，实际结论很明确：更新 CMS 或其插件也许是必要的，但修复这些漏洞还需要更新 PHP 运行时。这个问题既可能影响一个定制开发的业务系统，也可能影响一个 WordPress 网站。
哪些 PHP 和 Node.js 版本包含修复
各项目针对 10 月 21 日公告给出的上游版本如下：
| 运行时 | 分支 | 修复版本 |
|---|---|---|
| PHP | 8.2 | 8.2.35 |
| PHP | 8.3 | 8.3.36 |
| PHP | 8.4 | 8.4.27 |
| PHP | 8.5 | 8.5.12 |
| Node.js | 22 | 22.23.4 |
| Node.js | 24 | 24.22.1 |
| Node.js | 26 | 26.12.1 |
此表汇总了 PHP 版本发布 和 Node.js 安全公告 的信息。它并不是建议每个应用都直接跳到最高的主版本：首先要确认兼容性、依赖和原生扩展。
还有一个会改变判断的细节：仅凭上游版本号不足以判断一个 Linux 软件包。发行版可以在保留看似老旧的基础版本号的同时应用修复。例如，对于 Ubuntu 24.04 上的 PHP 8.3，CVE-2026-109618 和 CVE-2026-109619 的官方页面列出的已修复软件包是 8.3.6-0ubuntu0.24.04.13。必须查看完整的修订号和供应商的公告。同样的原则也要求对已停止支持的分支格外留意：你需要供应商有文档记录的修复，或者迁移到仍在维护的分支。
从外部做检查也有同样的局限。我们的瑞士公共部门安全普查每天仅使用公开数据，检查约 2200 个市镇、州和联邦机构，并以被动方式将网站在响应头中声明的 PHP 版本与修复版本进行比较。这对掌握整体情况是有用的线索，但不是诊断：很多服务器并不显示版本号，而一个已由发行版应用修复的软件包看起来也可能很旧。要知道真正在运行的是什么，必须深入服务器内部去看。
Node.js、Brotli 与压缩背后的风险
Node.js 10 月安全公告 中包含 CVE-2026-111497，这是 Brotli 解码器中的一个高危缺陷，可能导致远程代码执行。Brotli 是一种压缩格式，在网络流量中也有使用。实际暴露程度取决于应用通过哪些路径处理攻击者可控的压缩数据；仅仅安装了 Node.js，并不能证明漏洞可被利用。
同一版本还包含对 DNS、TLS 证书验证和其他组件的修复。因此，我们更新了受影响的运行时，并对压缩、TLS 初始化和加密功能做了验证。一个能正确压缩和解压数据的测试，检验的是新环境的兼容性；而补丁是否包含在内，要靠修复后的版本号和经过验证的软件来源来证明。
对于仍在使用 Node.js 20 的应用，我们准备了迁移到受维护分支的方案。原生扩展值得单独测试：为旧版运行时编译的 SQLite 模块，在更换主版本时可能需要重新编译。
为什么更新服务器不会自动更新 Docker 和 PM2
在真实的基础设施上，系统自带的 PHP、Apache 容器里的 PHP，以及某个 PHP-FPM 应用使用的 PHP 可能同时存在。修复其中一个，其他的还是原样。就连终端命令返回的版本，也要和实际处理请求的进程版本进行比对。
对于 Docker，我们检查了实际在用的镜像，准备了替换镜像，并保留了数据卷。一个名为 latest 的标签并不能证明其中包含补丁；如果 Dockerfile 或部署流程仍在选用旧的基础镜像，将来的一次重新构建就可能让之前的工作前功尽弃。在这次处理中，我们还核对了供应商提供的软件包，并在必要时从官方源码构建运行时，同时校验了校验和。
对于 PM2，修改 shell 的默认 Node 并不会替换已经加载到内存中的可执行文件。我们检查了守护进程、子进程以及 systemd 的监管。过程中也需要回滚和修正操作流程：能够随时回到一个可用的配置，本身就是准备工作的一部分。
更新 PHP 和 Node.js，而不丢失定制和数据
切换之前，我们保留了原有镜像，并为测试准备了数据库和数据卷的副本。在监控系统上，我们使用相同的只读挂载，将数千个 PHP 和 MIB 文件与原始快照逐一比对。在发票服务上，我们在克隆环境中测试了登录、读取客户和发票、下载已有 PDF 以及生成测试文档。随后在生产环境中再次检查了服务状态和 HTTP 响应。
业务系统的测试套件完成了数千个测试，无一失败。这些服务最后的受控重启，以及发票服务的最终切换，都没有造成中断：生产端点的监控一直收到正确的响应。整个过程中也有过尝试和回滚，而这些正是为了不影响最终用户而事先准备的。
健康检查显示绿色，只说明某一项特定检查通过了。要知道应用是否仍然可用，还需要测试真正重要的功能：登录、数据库、文档、任务队列和集成。这是瑞士主机托管管理中实实在在的一部分，需要在下一份紧急公告到来之前就安排好。
该向网站管理方提出的问题
有 VPN 保护的网站也需要更新吗？
需要。VPN 限制的是谁能通过它所保护的入口访问某个服务；修复消除的是运行时里的缺陷。两者作用不同。有 VPN 有助于评估暴露程度和安排处理顺序，但它不能代替补丁。
只更新 WordPress、Laravel 或 JavaScript 框架就够了吗？
对于这些漏洞，还需要检查 PHP 或 Node.js。请询问你的服务商：处理请求的是哪个版本，哪个软件包修订版包含修复，以及重启后完成了哪些检查。即使操作系统已经更新，应用仍可能继续使用它自己 Docker 镜像里的运行时。
更新之后能保证 100% 安全吗？
我们可以记录已安装的修复、已通过的测试和已完成的检查。但这并不能证明不存在任何其他漏洞，或此前没有被入侵过。例如，在检查过程中，我们单独记录了一条来自某个应用依赖的非致命警告，它在更换 PHP 之前就已存在。把安全补丁、兼容性和原本就存在的异常区分开，有助于做出合理的决策。
我们也可以为你的企业做这项检查
Webcracy 可以核实你的网站或业务系统正在运行哪些版本的 PHP 和 Node.js，检查修复是否到位，并找出需要优先更新的服务。我们会交给你一份概览，说明我们检查了什么、需要做哪些处理，以及还有哪些问题悬而未决。
我们也可以负责更新工作：准备备份、在数据副本上测试变更，并检查你每天使用的功能。事前我们会商定时间和方式；事后我们会记录所做的变更和执行的测试。
告诉我们你在用什么，以及目前由谁管理你的主机托管：我们就从那里开始，必要时也可以和你现在的服务商一起合作。
示意图片：Taylor Vick 发布于 Unsplash，依据 Unsplash 许可 使用。图中的数据中心并非本次处理所在的数据中心。