PHP 与 Node.js 紧急安全更新：2026 年 10 月高危漏洞报告与修复指南

核验日期：2026 年 10 月 22 日，北京时间。本文聚焦 PHP 与 Node.js 官方于 2026 年 10 月 21 日发布的本轮安全更新。表中版本是本轮漏洞的修复基线；后续更新请继续核对官方公告。文中的排查与验收步骤用于防守和运维，不包含漏洞利用代码。

2026 年 10 月 21 日，PHP 与 Node.js 分别发布安全更新。PHP 修复了两个可导致未认证远程代码执行的严重漏洞；Node.js 修复了 Brotli 解码器越界写入，以及 DNS、TLS 校验相关高危问题。使用这些运行时的网站、接口与后台服务，应尽快完成资产确认和补丁部署。PHP 官方公告、Node.js 官方公告给出了本轮修复信息。

本文把漏洞报告和修复操作放在一起：先判断是否受影响，再按部署方式更新，最后验证实际承载请求的进程是否已经切换。

一、先看修复版本

PHP：两个严重漏洞共用以下修复基线

| 当前分支 | 本分支受影响版本 | 本轮修复版本 |

| — | — | — |

| PHP 8.2 | 8.2.x 中低于 8.2.35 的版本 | 8.2.35 |

| PHP 8.3 | 8.3.x 中低于 8.3.36 的版本 | 8.3.36 |

| PHP 8.4 | 8.4.x 中低于 8.4.27 的版本 | 8.4.27 |

| PHP 8.5 | 8.5.x 中低于 8.5.12 的版本 | 8.5.12 |

以上版本对应 CVE-2026-109618 和 CVE-2026-109619。不要把表格理解为“更老分支不受影响”。PHP 8.1 及更早分支已结束上游常规安全支持，应迁移到受支持分支，或者取得发行版、长期支持供应商的明确修复证明。官方为 PHP 7.4、8.0、8.1 提供了本轮最小源码回移补丁，但这不代表恢复这些分支的完整支持。PHP 官方公告

Node.js：按当前主版本更新

| 当前分支 | 本轮安全版本 | 处理建议 |

| — | — | — |

| Node.js 22.x | 22.23.4 | 更新到本轮安全版本或同分支后续安全版本 |

| Node.js 24.x | 24.22.1 | 更新到本轮安全版本或同分支后续安全版本 |

| Node.js 26.x | 26.12.1 | 更新到本轮安全版本或同分支后续安全版本 |

三个版本均已发布。22.x、24.x 的发布页标注为 LTS，26.x 在本次发布时标注为 Current。已结束支持的旧分支不能因为未出现在修复表中就判断安全，应迁移到受支持分支。22.23.4 发布说明、24.22.1 发布说明、26.12.1 发布说明、Node.js 官方公告

发行版回移补丁例外： 如果使用 Linux 发行版或商业供应商维护的软件包，不应只比较上游版本号。请同时核对供应商公告、完整软件包版本及 changelog，确认相应 CVE 已修复。PHP 官方明确说明，发行版和长期支持供应商提前收到了补丁。PHP 官方公告

二、PHP 漏洞报告：风险发生在运行时内部

2.1 CVE-2026-109618：OOM 异常处理导致内存破坏

官方等级： Critical，CVSS v4.0 9.2。
问题位置： 内存不足（Out Of Memory，OOM）时的异常退出与请求清理。
潜在后果： 未认证远程代码执行，代码以 Web 工作进程的权限运行。

PHP 在部分内部数据尚未完成初始化时遇到内存分配失败，可能提前退出当前处理流程。随后进行请求清理时，这些无效数据可能被当作有效状态使用，形成内存破坏。官方确认，在 Apache mod_php 的相关默认配置下，已通过 HTTP 请求验证远程代码执行，且触发过程可以早于业务代码执行。CVE-2026-109618 技术公告

这意味着，修补业务控制器、增加登录校验，不能覆盖发生在应用执行之前的这条路径。补丁必须落到 PHP 运行时。

2.2 CVE-2026-109619：跨请求遗留状态导致释放后使用

官方等级： Critical，CVSS v4.0 9.2。
问题位置： 请求结束后，工作进程仍保留指向已释放请求内存的内部状态。
潜在后果： 释放后使用（Use After Free）、信息泄露及远程代码执行。

当一个请求结束，而相关全局状态未正确清理时，同一工作进程处理后续请求可能再次访问旧内存。能否利用取决于具体代码路径、配置及请求是否落到同一工作进程，不能据此认为多进程部署已经消除风险。CVE-2026-109619 技术公告

2.3 哪些 PHP 部署需要检查？

PHP 官方将提供 Web 请求处理的 PHP 部署纳入风险范围，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed，并认为 mod_php 风险最高。使用 Nginx + PHP-FPM 不能作为跳过更新的理由。PHP 官方公告

两份技术公告对验证程度作了区分：OOM 漏洞已在 mod_php 上验证完整利用，FPM 的相关风险有源码分析支持，但尚未展示完整利用；遗留状态漏洞的会话生命周期路径则已在 mod_php 和 FPM 上验证，FPM 场景依赖合适的应用操作。不同配置的利用条件不同，均应按公告更新。OOM 技术公告、遗留状态技术公告

建议先处理公网入口、上传与导入接口，以及承载多站点的共享运行环境。这里的处理顺序是运维建议，不代表只有这些业务路径受影响。

三、Node.js 漏洞报告：关注解压、DNS 与 TLS

本轮公告包含四个高危问题。下表使用 Node.js 官方的 High 等级，不自行补填 CVSS 分数。Node.js 官方公告

| CVE | 官方披露的问题 | 官方列出的受影响分支 |

| — | — | — |

| CVE-2026-111497 | Brotli 解码器越界写入，可导致远程代码执行 | 22.x、24.x、26.x |

| CVE-2026-105482 | dns.resolve 对包含 NUL 字符的名称发生截断 | 22.x、24.x、26.x |

| CVE-2026-105483 | 使用全角数字表示 IP 地址时，TLS 证书主机名校验可被绕过 | 24.x、26.x |

| CVE-2026-106069 | 主机名被宽松解析为 IP 地址时，TLS 证书主机名校验可被绕过 | 22.x、24.x、26.x |

来源：Node.js 安全公告及各分支发布说明。

3.1 Brotli：检查实际发生解码的位置

针对 CVE-2026-111497，应盘点应用是否处理外部来源的 Brotli 压缩数据。建议检查内容抓取、文件处理、HTTP 客户端和显式调用解压 API 的代码。Node.js 的 node:zlib 提供 Brotli 解压接口；仅看到站点启用“响应压缩”，不足以判断本漏洞的具体暴露路径。Node.js 安全公告、zlib 文档

上述场景属于排查建议，并不表示官方确认每种业务配置均可被利用。实际风险还取决于不可信数据能否到达解码器。

3.2 DNS 与 TLS：检查输入与校验是否一致

建议检查接受外部域名、URL 或回调地址的业务：是否对原始字符串做了允许列表判断，又将不同表示形式交给 DNS 或 TLS 层处理。涉及代理、Webhook、SSRF 防护或自定义证书校验的系统，适合优先回归测试。

这是根据漏洞类型提出的审计方向，不应直接写成“这些 CVE 必然造成任意 SSRF”。DNS 解析、URL 规范化和业务授权之间的具体影响，需要结合应用实现确认。

Node.js 本轮还修复了中低危问题并更新内置依赖，因此应部署完整安全版本；只更新项目中的某个 npm 包，不能证明 Node.js 内置组件已完成修复。Node.js 官方公告、24.22.1 发布说明

四、第一步：确认实际使用的运行时

4.1 PHP 基础排查

在 Linux 主机或对应容器内执行：


command  -v  php

php  -v

php  --ini

  

# 查看 PHP、FPM、Apache 相关进程

ps  -eo  pid,ppid,args | grep  -E  '[p]hp|[a]pache2|[h]ttpd'

这些命令帮助确认命令行 PHP 和进程信息，但验收还应覆盖 Web SAPI。建议通过仅管理员可访问的现有诊断入口，读取 PHP_VERSION、PHP_SAPI 和 php_ini_loaded_file()，核对真实请求使用的版本与配置；不要公开部署完整 phpinfo() 页面。PHP 运行时信息文档

4.2 Node.js 基础排查


command  -v  node

node  --version

node  -p  'JSON.stringify({node: process.version, execPath: process.execPath, openssl: process.versions.openssl}, null, 2)'

  

# 查看 Node.js 进程的启动命令

ps  -eo  pid,ppid,args | grep  '[n]ode'

process.version、process.execPath 和 process.versions 可用于记录运行时版本、可执行文件路径及内置组件信息。Node.js process 文档

建议让实际应用在启动日志中记录这些字段。当前终端的检查结果，需要与 systemd、进程管理器或容器启动的服务对应起来。

五、第二步：按部署方式更新

以下命令均为示例，应先确认版本、包名和服务名适合当前环境。涉及服务重启的步骤应在维护窗口执行，集群可逐实例切流、更新和验收。

5.1 Debian / Ubuntu：以 PHP 8.4 + FPM 为例

前提：系统已经安装 php8.4-cli、php8.4-common、php8.4-fpm，且当前软件源提供本轮修复包。其他分支需替换包名；Apache mod_php 用户应更新对应模块包并重启 Apache。

先刷新索引、查看候选版本：


sudo  apt-get  update

apt-cache  policy  php8.4-cli  php8.4-common  php8.4-fpm

核对候选包及供应商公告确认已修复两个 PHP CVE 后，再执行升级：


sudo  apt-get  install  --only-upgrade  php8.4-cli  php8.4-common  php8.4-fpm

  

# 配置测试成功后再重启

sudo  php-fpm8.4  -t

sudo  systemctl  restart  php8.4-fpm

sudo  systemctl  is-active  php8.4-fpm

  

php  -v

同时检查已安装的 PHP 扩展包是否需要配套更新。如果软件源尚未提供补丁，命令成功或显示“无需升级”均不代表安全。APT 使用说明、PHP 官方公告

对于宝塔、1Panel、cPanel 或托管平台，请在相应管理系统中确认每个站点绑定的 PHP 实例已更新；主机默认 CLI 版本不能代替站点验收。

5.2 nvm 环境：以 Node.js 24.x 为例

以下示例适用于已经安装并正确加载 nvm-sh/nvm 的 Linux/macOS shell。Windows 原生安装和其他版本管理器应使用各自的升级方式。


nvm  install  24.22.1

nvm  use  24.22.1

node  --version

如果项目使用 .nvmrc，在项目目录同步版本：


printf  '%s\n'  '24.22.1' > .nvmrc

nvm 的安装、切换和 .nvmrc 用法见官方项目说明。原本运行 22.x 或 26.x 的项目，可先分别更新到 22.23.4 或 26.12.1；跨主版本迁移应另外安排兼容性测试。

随后更新部署配置中的 Node.js 路径，并重启实际应用。systemd 服务应核对 ExecStart；进程管理器应核对解释器路径。仅执行 nvm use，不能作为后台进程已经完成升级的验收依据。

5.3 Docker / Compose：更新基础镜像并重建服务

建议按以下顺序操作：

将 Dockerfile 的基础镜像更新到供应方已发布、包含修复的版本，并核对镜像摘要。
重新构建应用镜像，而不只是重启原有容器。
重建服务，在新容器内核对运行时版本。

以下示例假设 Compose 服务名为 php、app，且两者通过 Dockerfile 构建；请替换为项目实际名称：


docker  compose  build  --pull  --no-cache  php  app

docker  compose  up  -d  --force-recreate  php  app

  

docker  compose  exec  php  php  -v

docker  compose  exec  app  node  --version

--pull、--no-cache 和 --force-recreate 的行为见Compose build 文档与Compose up 文档。如果服务直接引用成品镜像，应修改 image: 到已确认修复的标签或摘要，拉取新镜像后再重建。

CI 构建镜像、定时任务镜像和独立消费者也应进入同一轮盘点，避免下一次发布重新带回旧运行时。

5.4 Windows 与 Apache：替换运行时并重启对应服务

对于原生 Windows 部署，先确认服务实际加载的 PHP 目录，以及 Apache 模块、FastCGI 或其他集成方式。使用 PHP 官方修复构建时，应匹配原有架构、Thread Safe / Non Thread Safe 类型及扩展兼容性，保留并核对 php.ini，随后重启相应 Web 服务。官方安全公告提供了源码和 Windows 二进制的下载入口。PHP 官方公告

Node.js 可使用对应修复版本发布页提供的 Windows 安装包更新，完成后重启应用及其服务管理进程。Node.js 24.22.1 发布页

可在 PowerShell 中检查命令行路径和版本：


where.exe php

php -v

where.exe node

node --version

若存在多个安装目录，仍需通过 Web 诊断入口、服务启动路径或应用启动日志确认实际使用的版本。

六、暂时不能升级时，哪些措施有用？

6.1 PHP：只能临时降低部分路径的暴露

PHP 官方明确说明：只有更新才是完整解决方案，配置调整不能使未修复实例变得安全。PHP 官方公告

针对遗留状态漏洞，官方给出以下局部缓解措施：


; 在请求解析之前生效的 php.ini 或服务器级配置中设置

session.upload_progress.enabled = 0

对于 PHP 8.5，还可在相应配置中关闭：


; 仅适用于 PHP 8.5 对应路径

fatal_error_backtraces = 0

修改后必须重启所有相关工作进程。不要依赖业务代码中的 ini_set() 或 FPM .user.ini 来阻断已发生在其之前的处理路径。这些设置仅覆盖已知路径，不等于消除全部变体。CVE-2026-109619 技术公告、PHP 官方公告

针对 OOM 问题，可在入口限制请求体与 multipart 资源消耗；不过单独调低 post_max_size 也不能替代补丁。CVE-2026-109618 技术公告

官方还讨论了临时设置 memory_limit=-1 的方案：它可移除可控的 PHP 内存限额失败，但底层分配失败仍可能触及漏洞。该方案需要结合外部资源边界评估，不能直接当作通用修复命令；完整条件应按官方 OOM 公告逐项核对。

若采用该临时方案，应在管理员级配置中强制执行，确认池、目录与应用配置没有恢复有限的 memory_limit，并重启所有工作进程；入口限制还需覆盖解码后的请求体和无有效 Content-Length 的请求。官方建议结合容器或 cgroup 资源边界，并明确要求不要用 RLIMIT_AS 或 RLIMIT_DATA 替代，因为它们可能导致底层分配失败并触发相同漏洞路径。PHP 官方公告

6.2 Node.js：收紧不可信输入，保持证书校验

在部署更新前，建议减少不必要的外部压缩数据处理，对外部 URL 使用明确的协议、目标和出口策略，并保持 TLS 校验开启。这些属于临时加固建议，不构成针对全部漏洞的修复证明。

不要为了让请求恢复成功而设置 NODE_TLS_REJECT_UNAUTHORIZED=0，或通过 rejectUnauthorized: false 关闭验证。Node.js 官方文档说明，关闭 TLS 验证会使连接不安全。Node.js 环境变量文档、TLS 文档

七、第三步：验证补丁确实进入生产进程

建议把以下项目纳入变更验收：

☐ PHP / Node.js 已达到本轮修复版本，或有明确的供应商回移补丁证明。
☐ Web PHP、命令行、后台任务和容器实例分别完成版本核对。
☐ 实际承载请求的进程已重启或替换，启动日志能对应到新版本。
☐ PHP 扩展、Node.js 原生模块与关键业务流程完成兼容性检查。
☐ 上传、导入、会话、登录、外部 HTTPS 请求和压缩数据处理完成回归。
☐ CI 镜像、Dockerfile、版本文件及部署配置已同步更新。
☐ 验收记录保存了实例、包版本或镜像摘要、重启时间与负责人。

7.1 日志用于排查，不能单独证明安全

PHP 官方建议检查请求初始化前后的警告、清理阶段诊断、致命错误及超时等现象，同时强调：日志没有异常，不能证明漏洞不可触发。CVE-2026-109619 技术公告

运维排查可结合进程崩溃、异常子进程、站点文件改动和异常外连进行交叉判断。这些是调查线索，并非本轮漏洞专属的攻击指纹；本文不提供未经验证的 IOC，也不把风险公告表述成所有站点已遭入侵。

若已有入侵迹象，建议隔离受影响实例、保全日志及相关证据，并按事件响应流程处理凭据和业务恢复。补丁部署与入侵调查应分别记录结果。

7.2 更新失败时如何回退？

建议优先回退业务代码，同时保留已修复运行时。若兼容性问题迫使实例临时恢复旧运行时，应限制其暴露面并继续安排修复，不能将其标记为漏洞已关闭。

八、维护建议：补丁版本与支持周期一起管

PHP 8.2 的上游安全支持计划于 2026 年 12 月 31 日结束。仍使用该分支的团队，应在完成本轮补丁后安排版本迁移。PHP 支持周期

建议资产清单至少记录：运行时分支、补丁版本、部署位置、软件源或镜像来源、支持结束日期，以及实际负责的业务团队。这样下一次安全更新到来时，可以直接定位需要变更的实例。

参考资料

以下为本文核验的官方公告、项目发布说明及操作文档。漏洞范围和修复状态如有后续修订，以原始公告为准。