企业业务系统也要查 PHP2Shell 吗？排查顺序和供应商确认清单

先给结论：要查。只要是处理 Web 请求的 PHP，都在 PHP2Shell 的影响范围内——它命中的是 PHP 运行时（CVE-2026-109618 与 CVE-2026-109619，CVSS v4.0 均为 9.2 分，无需登录即可尝试利用），和系统是谁开发的、界面新不新没有关系。企业真正容易漏掉的，恰恰是供应商多年前交付的老系统和被遗忘的测试站。官方已明确：没有完整的配置缓解办法，升级到修复版本是唯一完整修复，所以这件事的重点不是"要不要处理"，而是"按什么顺序把资产查全、处理完"。

哪些系统算在范围内？

• 官网与内容系统：用 PHP 建的企业官网、新闻发布系统、基于各类 PHP CMS 的站点；
• 业务系统：内部业务平台、客户或会员系统、部署在云服务器或机房里的 PHP 应用；
• 供应商交付的老系统：多年前外包开发、上线后很少动过的系统，PHP 版本往往停留在很老的分支；
• 被遗忘的环境：测试站、演示站、管理后台、迁移后没下线的旧版本——它们同样对外可达，却常常不在日常运维清单里。

原理拆解见知识中心的《PHP2Shell 原理拆解》一文；本文只讲排查与推进。

排查顺序是什么？

1. 先清点 PHP 资产：把所有对内、对外运行 PHP 的服务器和站点列成一张表，包括测试与备份环境，先求全，再求细；
2. 逐台查版本：记录每套环境的 PHP 版本号，对照修复版本判断是否受影响（对照表见下文）；
3. 分清维护责任：每套系统标注是自维护还是供应商维护，供应商维护的立即进入确认流程，不要等对方主动通知；
4. 升级或隔离：能升级的尽快升级到修复版本并重启 PHP 服务；暂时升不了的，先下线或隔离到不可从公网访问，不要裸奔等待；
5. 升级后复核与入侵排查：确认新版本号已生效、服务已重启；同时排查是否已被入侵——检查异常新增文件、异常进程，以及日志中是否出现过异常请求激增。漏洞公开后扫描和利用出现得非常快，"没出事"不能靠假设。

修复版本对照表

向供应商确认哪 5 个问题？

1. 我们这套系统当前用的 PHP 版本具体是多少？是否在受影响范围内？
2. 是否已经打上修复补丁（升级到上表对应版本）？如果已处理，请提供升级后的版本号截图或记录。
3. 如果还没处理，计划在什么时间完成？等待期内有什么临时隔离措施？
4. 如果系统跑在 PHP 8.1 或更早版本上，迁移到受支持版本的方案和时间表是什么？
5. 升级后由谁负责重启 PHP 服务并做生效验证？验证结果以什么形式反馈给我们？

这 5 个问题建议以书面形式发出并留存回复。尤其是第 2 和第 5 个：只说"已经修复"不够，要拿到版本号和重启验证的结果。

暂时升不了级怎么办？

先隔离，后升级。WAF 等防护规则只能作为临时缓冲，官方明确表示不存在完整的配置级缓解办法，因此不要把"加了防护规则"当作处理完毕。确实无法立即升级又不能下线的系统，至少应限制访问来源、加强日志监控，并把升级排期定死、责任到人。

日常怎么减少这类风险？

这类事件真正的教训在资产管理：版本台账不清、老系统无人认领，才是排查时最耗时的部分。把 PHP 版本、维护方、联系人维护成一张常更新的表，下一次出现紧急漏洞时就能直接进入处理环节。更多企业系统运维与数字化管理的内容，可浏览知识中心栏目。