针对 CVE-2026-109618（PHP2Shell）这类 CVSS 9.2、无需认证即可触发、且已在补丁发布前出现利用迹象的 PHP 核心级远程代码执行漏洞，公司网站的防护不能停留在“改应用代码”的层面，而必须按照运行时修补、边界缓解、暴露面收敛、长期版本治理四条线并行推进。核心原则只有一个：唯一完整的修复方式是更新 PHP 运行环境本身，任何配置调整或 WAF 规则都只是为修补争取时间的临时手段。
第一步：立即确认是否处于受影响范围
CVE-2026-109618 影响 PHP 5.4 至 8.5.11 的广泛版本区间，涵盖 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed 等主流 Web 运行方式，其中 Apache mod_php 的风险最高，官方已在 mod_php 环境中验证了无需认证的远程代码执行。公司应首先通过主机资产清点、容器镜像扫描或专门的检测工具，确认所有对外提供 HTTP 服务的 PHP 进程版本。如果发现版本落在 8.2.35、8.3.36、8.4.27、8.5.12 以下，即视为受影响，必须在第一时间纳入修补队列。
第二步：能升级的，立即升级到安全版本
理论上，运行受支持 PHP 8.x 分支的服务器可以在数分钟到数小时内完成包管理器层面的补丁安装。各分支的安全版本为：PHP 8.5.12、8.4.27、8.3.36、8.2.35。对于仍在使用 PHP 8.1、8.0 或 7.4 的站点，PHP 官方已为这些已结束常规支持的分支提供了源代码反向移植补丁，部分 Linux 发行版和 LTS 服务商也可能回移了安全更新，应尽快向供应商确认并应用。需要特别警惕的是，PHP 5.x 和 7.x 的早期分支已完全停止官方支持，不会收到官方修复，这类服务器必须迁移到受支持的安全分支，而不能抱着“没有新补丁就暂时安全”的侥幸心理。
升级后还有两个容易遗漏的动作：一是重启全部 PHP 工作进程，否则旧进程仍可能继续以受影响的状态运行；二是核验实际生效的 `php.ini` 和 `php_admin_flag` 是否被应用配置或容器镜像覆盖，确保补丁后的运行时配置没有被回退。
特别是使用宝塔面板的服务器，建议使用宝塔官方提供的修复及防护方案https://docs.bt.cn/notices/php-security-protection-guide/。宝塔已为 Linux 的 PHP 7.0、7.1、7.2、7.3、7.4、8.0、8.1 提供安全修复包，帮助仍依赖旧版 PHP 的用户完成本次漏洞修复。PHP 7 和 PHP 8 的修复版本均已上线面板软件商店；PHP 5.4、5.5、5.6 修复版目前通过命令开放测试。其中，PHP 5.6.42 采用 AI 辅助与人工代码对比的方式完成漏洞修复。
第三步：无法立即升级时，用临时缓解措施压低风险
对于业务耦合深、升级窗口尚未打开的系统，可以立即采取以下临时缓解，但必须清醒认识到它们不能替代补丁：
禁用 `session.upload_progress.enabled`。这是 CVE-2026-109619 确认利用路径的关键开关，在 `php.ini` 中设置为 `Off`，并在使用 PHP-FPM 时同步修改对应的 `php_admin_flag`，可以阻断已知的会话上传进度利用链。但该措施并不完整，CVE-2026-109618 的 OOM 路径仍可能通过其他畸形请求触发。
限制请求体与内存行为。在应用允许的范围内，将 `post_max_size` 调低（不接受上传时建议 8M，接受上传时可考虑 32M），并收紧反向代理或 Web 服务器对 multipart 请求的解码限制；对于明确不接收文件上传的端点，可在 Web 服务器或代理层直接阻断 `multipart/form-data` 请求。
启用 WAF 虚拟补丁。Cloudflare、AWS WAF、腾讯云 WAF 等主流云 WAF 已在漏洞披露后快速上线了针对 CVE-2026-109618/109619 的专用规则或虚拟补丁，应在升级完成前保持 WAF 防护开启，并将其视为争取修补窗口的边界缓冲，而非最终方案。
第四步：修补之外，收敛暴露面并准备检测
如果存在暂时无法下线或无法修补的旧版本系统，CISA 的建议是：考虑将系统临时下线，或至少将面向互联网的 PHP 应用与公共网络隔离，直至补丁完成验证。同时，应针对 PHP 工作进程的异常子进程创建、可疑文件写入、异常出站连接等后渗透行为配置检测规则；PHP2Shell 的攻击特征之一是“不落地网页后门文件即获取代码执行”，传统文件哈希查杀难以覆盖，运行时行为监控比事后文件扫描更有意义。
长期治理：把“版本支持状态”纳入安全基线
参考内容中有一个值得所有运维团队正视的数据：约 73% 的 PHP 网站仍在运行已过支持期的版本，约 7.7% 仍在使用 PHP 5.x。这类“补丁来了也打不上”的资产，在下一次核心漏洞爆发时仍会重复同样的被动局面。从 PHP 7 升级到 8 的主要工作量集中在删除已弃用函数、替换被移除的库、修复破坏性变更，核心语言特性的改动相对有限；PHPCompatibility、Rector 等静态分析工具和自动化修复工具可以覆盖相当一部分机械性迁移工作，AI 辅助重构工具也在逐步成熟。将 PHP 运行时的“支持生命周期”纳入资产台账和发布门禁，比每次漏洞爆发后临时找补丁更具可持续性。
FAQ问答：
Q1：公司网站用的是 PHP 7.4，官方已经停止支持，是不是打不了这个补丁？
不是。PHP 官方虽然已结束 7.4 的常规安全维护，但针对 PHP2Shell 这类严重漏洞，仍为 7.4、8.0、8.1 分支提供了源代码反向移植补丁，部分 Linux 发行版和 LTS 服务商也可能回移了修复。正确的做法是：先向操作系统/发行版供应商或 PHP 构建来源确认是否已有包含修复的软件包并尽快安装；如果无法获得可信的回移补丁，则应将升级到 PHP 8.2 或更高受支持分支作为修复计划的一部分，而不是继续停留在 7.4 上等待。
Q2：已经启用了 WAF，也禁用了 `session.upload_progress`，是不是就可以不升级 PHP 了？
不可以。禁用 `session.upload_progress` 只能阻断 CVE-2026-109619 的一条确认路径，不能完整覆盖 CVE-2026-109618 的 OOM 触发面；WAF 虚拟补丁同样只是基于已知攻击特征的边界拦截，无法保证对所有变形请求持续有效。WAF 和配置缓解的正确定位是“升级完成前的临时风险降低措施”，修补 PHP 运行时仍然是唯一完整的修复方式。
Q3：升级 PHP 之后，还需要做什么才能确认风险已经消除？
升级到安全版本并重启全部 PHP 工作进程之后，需要做三件事：一是重新核验实际加载的 PHP 版本和 `php.ini`/`php_admin_flag` 配置，确认没有被应用层或容器编排配置覆盖回旧值；二是检查升级前的时间窗口内是否出现过异常 PHP 进程、可疑文件写入或异常网络连接，PHP2Shell 利用可能在补丁前已经发生；三是对面向公网的 PHP 端点做一次最小化的验证请求，确认 WAF 规则、上传限制和会话配置在升级后仍然按预期生效。