PHP 爆出无需登录即可远程控服的重大漏洞：等保测评会怎么判这一项
这两天不少单位的运维都收到了同一条提醒：服务器上的 PHP 要升级。2026 年 10 月 21 日，PHP 官方一次性发布四个版本，修复两个严重漏洞。这件事之所以需要单独拿出来说，是因为它和以往常见的网站程序漏洞不是一回事。
一、这次出问题的不是某个网站程序
先说清楚问题出在哪。过去很多次安全通告，针对的是 WordPress、Drupal、ThinkPHP 这类具体程序，处置方式通常是升级程序或者装补丁。而这次的情况是，漏洞在 PHP 解释器本身，属于支撑这些程序运行的底层。
两个漏洞的编号是 CVE-2026-109618 和 CVE-2026-109619，社区里习惯合称为 PHP2Shell。按 PHP 官方安全团队给出的评级，两者的 CVSS v4.0 均为 9.2 分，属于最高一档。它们的成因可以这样理解：
- CVE-2026-109618：PHP 在处理内存耗尽时会提前退出当前上下文，如果这时请求内的数据还没初始化完成，随后的清理流程就会把无效数据当成有效数据来处理，造成内存破坏。
- CVE-2026-109619：处理完一个请求后，解释器没有把指向该请求内存的全局状态清干净，下一个请求进来时访问到了已经释放的内存，形成跨请求的释放后重用。
官方公告里有一句判断值得留意：在 Apache mod_php 场景下，攻击过程完全发生在任何应用代码开始执行之前。这句话的实际含义是，网站程序里写的登录校验、输入过滤，乃至部署在前面的常规防护规则，都还没来得及介入，攻击就已经完成了。
所以这次不是"哪个网站程序有洞"，而是只要这台服务器上跑的 PHP 版本在受影响范围内，运行其上的所有 PHP 站点都在同一风险面上。受影响的版本和对应的修复版本如下：
| 受影响范围 | 修复版本 | 该分支状态 |
|---|---|---|
| PHP < 8.5.12 | 8.5.12 | 正常维护 |
| PHP < 8.4.27 | 8.4.27 | 正常维护 |
| PHP < 8.3.36 | 8.3.36 | 正常维护 |
| PHP < 8.2.35 | 8.2.35 | 2026 年 12 月 31 日终止支持 |
| PHP 8.1 及更早（含 7.x、5.x） | 无官方更新 | 已停止支持 |
对已经停止支持的分支，PHP 官方这次破例提供了 7.4、8.0、8.1 三个分支的最小化源码补丁，方便自行编译的用户应急。但官方同时明确，这些分支不再获得来自 PHP 项目的更新，长期仍应迁移到受支持的版本。如果用的是发行版提供的长期支持包，可以联系发行厂商确认是否已有回移修复。
二、为什么这次的处置要往前排
有三个原因决定了这件事不能按常规节奏处理。
第一，无需认证、无需用户交互。攻击者不需要拿到任何账号，也不需要诱导内部人员点击，只要目标的网络可达，就能构造请求触发。这一点把防护的重心直接压到了补丁上——依赖身份鉴别体系来拦截是拦不住的。
第二，公开当天就已确认在野利用。本次原计划协调披露，因信息提前泄露而提前公开，多家安全机构的蜜罐网络在公开当日就观测到了利用尝试，技术分析细节也随之公开。这意味着防守方几乎没有缓冲时间，暴露在互联网上的系统处于持续被扫描的状态。
第三，官方没有给出完整的替代方案。PHP 官方公告的原话是"没有完整的缓解措施，升级更新是唯一安全的选择"。官方确实给出了一批临时缓解配置，但同时说明了这些措施不能使系统变得安全，只能作为暂时无法升级时的权宜之计。
三、等保标准把这件事归在哪一栏
从等保的角度看，这类事件有非常明确的对应条款，主要集中在安全计算环境层面。
《信息安全技术 网络安全等级保护基本要求》（GB/T 22239-2019）第三级 8.1.4.4 入侵防范的 e) 项要求：应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞。这是本次事件最直接的条款落点。二级系统同样有对应要求，只是具体要求项数量少于三级。
除此之外还有两条配套要求：
- 8.1.5.4 e）：应对安全策略、恶意代码、补丁升级等安全相关事项进行集中管理。这条对应的是补丁台账——对 PHP 这种可能同时存在于物理机、虚拟机、容器、共享主机上的运行时，没有统一的版本台账很难满足。
- 8.1.10.5：应采取必要的措施识别安全漏洞和隐患，对发现的安全漏洞和隐患及时进行修补或评估可能的影响后进行修补。这条属于管理要求，看的是单位有没有形成完整的识别与处置记录。
需要说明一点：标准用的词是"及时"，国家标准层面并没有给出一个统一的"X 小时修完"的强制时限。地方规范性文件里有"整改期限最长不超过 3 个月"这类表述，政府采购合同里常见"30 个工作日内完成整改可享一次复测"的约定，行业内对高危项通常按 15 至 30 日闭环来掌握。这些都不是国标原文，引用时要注意区分。
四、正式测评时会怎么判
这是各单位最关心的部分，可以拆成三个层次。
第一层是测评单元的判定。《信息安全技术 网络安全等级保护测评要求》（GB/T 28448-2019）中对应的测评单元要求通过漏洞扫描、渗透测试两种方式核查是否不存在高风险漏洞，并核查是否在充分测试评估后及时修补，两项均为肯定才符合。该单元的测评对象明确包含中间件和系统管理软件，PHP 运行时即属于此列。
第二层是高风险判定。《网络安全等级保护测评高风险判定指引》中，触发项"存在可被利用的高危安全漏洞"对应的测评单元适用于二级及以上系统。可触发的具体情形包括：通过互联网访问的系统存在外界披露的可被利用的高危安全漏洞，以及经测试验证确认存在远程代码执行等可被利用的高危漏洞。本次事件两条都占。
第三层是对结论的影响，这也是最容易被忽视的一层。按 2025 版测评报告模板，结论判定规则是：
| 结论 | 判定依据 |
|---|---|
| 符合 | 符合率高于 90%，且无重大风险隐患 |
| 基本符合 | 符合率高于 60%、低于 90%；或符合率虽在 90% 以上但存在重大风险隐患 |
| 不符合 | 符合率低于 60% |
这条规则的实际效果是：其他条款做得再完备，只要有一台面向互联网、运行着未修补 PHP 版本的 Web 服务器，今年的测评结论最高只能是"基本符合"。对于需要"符合"结论的单位，这个影响是直接而具体的。
五、排查时最容易踩的三个坑
处置的第一步是找全，而这一步恰恰是最容易出问题的。
不要只执行 php -v。 很多服务器上，命令行使用的 PHP 与承载 Web 请求的 PHP-FPM 是两个不同的二进制文件，各自读取不同的 php.ini，版本可能并不一致。可靠做法是临时输出 PHP_VERSION、PHP_SAPI 与 php_ini_loaded_file() 的实际值，确认完之后立即删除该临时文件。
不要只看包管理器的版本号。 发行版通常会在自身版本号后追加修订号，页面显示的版本号往往停留在上游的旧版本，但补丁已经通过回移方式打进去了。正确做法是查看该软件包的更新日志，确认其中是否包含本次的两个 CVE 编号。
注意面板与容器。 通过运维面板看到的版本未必是实际运行的版本；容器环境如果不强制拉取基础镜像，重建出来的还是带漏洞的那一层。此外，升级完成后必须重启——只替换二进制文件而不重启进程，常驻内存里的仍然是旧代码，风险一点没减少。容器环境要重建镜像，Kubernetes 环境要滚动重启全部 Pod，并确认没有旧的副本集还在对外服务。
六、暂时升不了级，能做什么
如果确实无法立即安排升级窗口，PHP 官方给出的临时缓解措施可以这样落地：
- 把 memory_limit 设为 -1，并且要用应用自身无法覆盖的方式设置，比如在 PHP-FPM 的 pool 配置里用 php_admin_value，或在 Apache 配置中设置，同时确认没有其他层级的配置又把它改回有限值。
- 把 post_max_size 设为 8M（不需要文件上传的场景）或 32M（需要上传的场景），并保证 upload_max_filesize 低于它。
- 在 Web 服务器或代理层限制解码后的请求体大小、输入字段数量、multipart 分片数量、每个分片的头部数量以及嵌套深度，这些限制要能覆盖那些没有携带 Content-Length 的请求。
- 把 session.upload_progress.enabled 设为 0，写入 php.ini 或 FPM pool 配置，并且重启每一个工作进程。不要依赖 ini_set() 或 .user.ini，那样生效得太晚。
同时有两个做法需要明确避开。一是不要用 RLIMIT_AS 或 RLIMIT_DATA 来做内存限制，官方明确指出这类限制会导致内存映射失败，反而会触发本漏洞所依赖的那条路径。二是不要把 WAF 当作整改完成，在官方明确表态没有完整缓解措施的前提下，防护设备只能作为辅助手段，不能作为测评时"已整改"的证明。此外，disable_functions、open_basedir 这类脚本层的限制对本漏洞同样无效，因为执行流在进入函数调用之前就已经被劫持了。
七、留痕：通报和排查记录本身就是证据
最后一件事常被忽略，但它直接影响测评判定。
在漏洞和风险管理相关的测评单元中，"安全通报"是被明确认可的漏洞识别记录形式之一。也就是说，单位如果收到了本次漏洞的官方或厂商通报，并据此形成了资产排查记录、版本核查记录、补丁升级与重启记录，以及升级后的验证记录，这套材料就构成了完整的证据链。反之，收到了通报但没有留下任何处置痕迹，在测评时会被判为不符合。
建议的节奏是：收到通报后尽快完成资产排查，在 72 小时内完成互联网侧的升级或临时隔离处置，整个过程保留书面记录，并纳入统一的补丁台账。这套动作同时满足三条条款的要求——漏洞的及时发现与修补、补丁的集中管理，以及漏洞和风险管理。
还需要提醒的是，如果怀疑系统已经失陷，处置重点要从升级转向应急：检查 Web 目录下新增或近期被修改的 PHP 文件，排查 PHP-FPM 与 Web 访问日志中的异常请求与崩溃记录，检查新增的计划任务与守护进程，关注可疑的对外连接，以及确认配置文件与密钥文件是否被读取。日志被清理本身就是重要的失陷信号。
需要一并说明的边界
最后澄清一个常见误解。本次 PHP 漏洞属于通用 Web 安全问题，与密码应用没有直接关联，不会直接产生密评的不符合项，也不属于需要向密码管理部门报告的密码相关安全事件。它只在间接层面影响设备和计算安全中的身份鉴别、日志记录完整性与可执行程序完整性这几项保护目标。把两件事强行挂钩的说法是不成立的，各单位在安排年度合规工作时可以按各自的周期分别推进。
如果您单位有对外提供服务的 Web 系统，而内部尚未建立 PHP 运行时的版本台账，建议借这次机会做一次完整的资产梳理——这类梳理对后续的差距分析、整改方案与年度测评都有直接价值。