2026 年 10 月 21 日，国家信息安全漏洞共享平台（CNVD）收录了 PHP 远程代码执行漏洞（CNVD-2026-41674、CNVD-2026-41675，对应 CVE-2026-109618、CVE-2026-109619），并发布安全公告（安全公告编号：CNTA-2026-0007），对该漏洞的综合评级为「高危」。

公告中有一句话值得所有运维负责人停下来读两遍：漏洞技术细节与 PoC 已广泛传播，CNVD 建议受影响用户立即升级至最新版本。这意味着它已经不属于「关注一下」的范畴，而是进入实战利用阶段。

一、漏洞情况

PHP 是广泛使用的开源通用脚本语言，适用于 Web 开发并可嵌入 HTML。其解释器内核为 WordPress、Drupal、Joomla、Laravel 等主流框架和内容管理系统提供基础运行时环境。

该漏洞源于 PHP 解释器内核在内存管理环节存在逻辑处理缺陷：攻击者可构造特定 HTTP 请求触发程序异常处理流程，导致内部数据状态异常或已释放内存被再次访问，从而引发内存破坏。未经身份验证的远程攻击者，可在特定条件下实现对目标服务器的拒绝服务攻击、敏感数据窃取、远程代码执行。

二、影响范围

已知受漏洞影响的 PHP 产品版本包括：

  • 8.2.35 版本之前的 8.2.x 版本；
  • 8.3.36 版本之前的 8.3.x 版本；
  • 8.4.27 版本之前的 8.4.x 版本；
  • 8.5.12 版本之前的 8.5.x 版本。

厂商发布的修复版本为 PHP 8.5.12、8.4.27、8.3.36、8.2.35。

此外，该漏洞还影响 Magento、WordPress、Drupal、Joomla、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS、OpenCart 等基于 PHP 环境的主流 CMS 和框架。

特别提示：8.1 及更早分支（含仍在不少老旧业务系统上运行的 8.0、7.x）已停止官方维护，不会获得本次补丁。这类环境只能通过升级大版本解决，缓解措施可以降低风险，但无法消除风险。

三、排查建议：先确认你到底在跑哪个版本

互联网用户可通过以下方式查看 PHP 使用版本，再对照影响范围判断是否受影响：

  • 使用 php -v 命令查询；
  • CLI 和 Web 服务器可能运行不同的 PHP 版本，网站实际使用的版本需使用 php-fpm -v 或 php-fpm8.3 -v 查询；
  • 面板或容器化部署的环境，还要核对面板内 PHP 池绑定、容器镜像标签，避免出现「面板显示已升级、实际仍在跑旧版本」的情况。

四、修复与缓解建议

修复：目前 PHP 安全团队已修复漏洞并发布安全公告，受影响用户应密切关注官方信息，通过官方渠道下载并更新至最新版本。

暂无法更新的用户，可采取以下措施减少部分攻击路径、缓解漏洞威胁：

  1. PHP-FPM 可设置 memory_limit=-1，移除可预测的单次请求内存限制；mod_php 环境关闭会话上传进度功能与 fatal backtrace：全局设置 session.upload_progress.enabled=0（PHP 8.5 可设置 fatal_error_backtraces=0），并重启全部工作进程或 Web 服务器。
  2. 阻断跨请求状态传递（此方式会降低服务性能）：FPM 池设置 pm.max_requests=1，mod_php 对应 Apache 的 MaxRequestsPerChild=1。
  3. 通过 WAF 等安全设备拦截异常 multipart/form-data 的 HTTP 请求。
  4. 持续监测 PHP 进程异常退出、系统异常命令调用、陌生进程创建、异常文件写入等行为，留存日志用于溯源分析。

防护建议：信息系统运营单位应进一步加强安全防护。全面梳理本单位网络资产，按照「非必要不上网」原则缩小信息系统的公网暴露面；暂不具备修复条件的运营单位，应采取网络隔离、网络访问限制、非必要业务系统下线等临时性应对措施。

五、这件事为什么会被反复强调「立即」

漏洞本身高危，但真正放大风险的是节奏。据公开报道，该漏洞在官方补丁发布前，相关预警信息已在技术社区提前外泄，网络安全厂商在补丁正式发布前数小时就已监测到首批攻击尝试。也就是说，攻击者拿到的时间窗口，比防守方完成一次变更窗口的时间还短。

这类「补丁尚未落地、攻击已经开始」的场景，正在成为常态。它对应的能力要求不是「知道有漏洞」，而是三件事：能不能在一小时内说清资产上有多少个 PHP 实例、能不能在一天内完成灰度与回滚、能不能在攻击发生时从日志里看出痕迹。

六、从合规角度看这次漏洞

漏洞处置不只是技术问题，它同时落在三条法定义务上：

  • 《网络安全法》第二十三条要求网络运营者按等级保护制度采取防范计算机病毒和网络攻击、网络侵入的技术措施，并留存网络日志不少于六个月——发现漏洞却不修复，本身就构成义务履行瑕疵；
  • 《公安机关网络空间安全监督检查办法》（公安部令第 176 号，2026 年 10 月 1 日施行）第七条将「是否依法采取措施整改漏洞、隐患，消除风险」列为十一项重点检查内容之一；
  • 等级保护测评中，漏洞扫描与风险评估是固定动作，未修复的高危漏洞会直接影响测评结论与整改闭环。

换句话说：这次升级不只是「运维该做的事」，它同时是等保测评、日常监管检查、以及万一出事后的责任认定所共同指向的动作。

七、我们的处置建议

第一步，清点。把全部 PHP 实例列成一张表：域名、服务器、PHP 版本、SAPI 类型（FPM/mod_php）、是否公网可达、业务负责人。漏掉一个 C 段里的测试站，等于没做。

第二步，分级。公网可达 + 处理个人信息或业务数据 + 无 WAF 的，优先升级；纯内网、有严格访问控制的，可以排后但仍需建账。

第三步，闭环。升级前做快照，升级后跑一轮功能回归与端口/服务核查；对无法立即升级的实例启用上述缓解措施，并写进整改台账，注明责任人与完成时间。

第四步，留痕。把「已排查、已升级、已缓解」的过程记录成文档。真到检查或出事时，这份记录是区分「已尽职」和「未履职」的关键。

本文依据 CNVD 公开发布的安全公告（CNTA-2026-0007）整理，技术细节与修复版本以官方公告及 PHP 官方安全公告为准。