PHP 安全警报：两个可未授权远程执行的漏洞，与一次教科书级的快速响应

PHP 安全警报：两个可未授权远程执行的漏洞，与一次教科书级的快速响应

2026 年 10 月 21 日，PHP 官方发布了本年度分量最重的一次安全更新：PHP 8.5.12、8.4.27、8.3.36 与 8.2.35 四个维护分支同步修复了两个被评为"严重"级别的远程代码执行漏洞（CVE-2026-109618 与 CVE-2026-109619）。按照官方公告的说法，攻击者可以在无需任何身份验证的情况下触发这两个漏洞，直接在服务器上执行任意代码。而就在漏洞披露后的第三天（10 月 23 日），PHP 团队又追加发布了一份关于 session upload progress 的信息性公告，补充了缓解措施。短短三天两次动作，加上正在推进的 PHP 8.6.0 RC4 测试周期，这波密集的安全响应值得每一位 PHP 从业者认真复盘。

两个漏洞到底是怎么回事

第一个漏洞 CVE-2026-109618 的攻击路径与内存管理有关。当 PHP 进程在处理请求时遇到内存耗尽（OOM），内部保存的请求数据可能只完成了一部分初始化。此时请求清理逻辑会把这些"残缺"的数据当作有效数据处理，从而为攻击者制造了可乘之机。官方特别强调，所有通过 PHP 对外提供 Web 服务的场景都在影响范围内——包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed，其中 mod_php 风险最高，官方已经复现了"一个未授权请求在应用代码尚未运行前就触发攻击"的完整利用链。

第二个漏洞 CVE-2026-109619 则源于"残留全局状态"。某个请求持有的内部状态在底层内存被释放后仍然存活，同一个 worker 进程处理的下一个请求可能会在正常初始化完成之前就用到这份过期状态。这类"脏状态跨请求泄漏"问题在 FPM 这类常驻进程模型下尤其值得警惕，因为它直接打破了请求与请求之间的隔离假设。

10 月 23 日的补充公告：细节里的魔鬼

漏洞修复了，故事却还没完。10 月 23 日，PHP 官方追加发布信息性公告，建议用户在下一个常规修复版本发布之前，将 session.upload_progress.enabled 设为 0。原因在于 CVE-2026-109619 存在一个概率极低但真实存在的 RCE 变体：当应用在配置中将 session.serialize_handler 设为 php_binary 或 php_serialize，随后又在运行时通过 ini_set() 切回 php，且 session upload progress 处于开启状态时，攻击面会重新打开。

官方坦言这种"配置与代码共同作用"的组合在实际中非常罕见，因此选择放进常规发布周期处理，完整的 CVE-2026-115560 公告将随下个版本一同发布。但这条公告传递的信号很明确：安全缓解措施要落在进程启动前的配置层，而不是依赖运行时的 ini_set()。这也是此次事件中很多团队容易踩的坑——以为自己打了补丁就万事大吉，却忽略了配置层的残留风险。

升级之外：官方给出的缓解清单信息量很大

如果暂时无法立即升级，PHP 安全团队给出了一份相当细致的临时缓解清单，这份清单本身就值得当作运维范本收藏：针对 OOM 漏洞，建议将 memory_limit 设为 -1（最好通过 php_admin_value 这类应用无法覆盖的方式）、收紧 post_max_size、在网关层限制请求体大小/字段数/嵌套深度；针对残留状态漏洞，建议关闭 session upload progress 并重启所有 worker、在 PHP 8.5 上设置 fatal_error_backtraces=0、清理会在初始化阶段产生诊断输出的无效配置项。

更贴心的处理是，考虑到大量存量系统仍停留在 7.4 / 8.0 / 8.1（这些版本早已停止官方维护），安全团队这次专门提供了这三个版本的源码级最小化补丁，帮助无法直接升级的团队先堵住眼前最急的洞。这种"官方给老版本兜底"的操作并不多见，也从侧面说明了这两个漏洞的严重程度。

PHP 8.6.0 RC4：安全修复同步跟上

与安全更新同日发布的还有 PHP 8.6.0 RC4。虽然只是测试版本，但官方特别强调 RC4 同样包含了这两个 RCE 漏洞的修复，所有运行早期 8.6.0 构建的用户必须立即更新。按照计划，下一个版本 RC5 将于 2026 年 11 月 5 日发布，这也是正式版发布前的最后一个候选版本。新特性方面可以关注官方 NEWS 与 UPGRADING 文档，8.6 的正式发布已进入倒计时。

生态侧同样在快速响应：Laravel 官方博客 Laravel News 第一时间发布了漏洞解读，PHP 基金会也发文介绍了此次漏洞披露过程中安全响应机制的强化，社区围绕"披露流程是否可以更快更透明"的讨论也在进行中。而 Laravel 13.38 版本则带来了防止读取脏数据库记录的改进，进一步强化了框架层的数据一致性保障。一个成熟的生态，正是在这种"出事—响应—复盘—改进"的循环中不断变强的。

给团队的三点行动建议

第一，今天就盘点线上 PHP 版本。8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 是本次的安全基线，mod_php 部署优先处理；还在 7.4~8.1 的系统要么走 LTS 厂商补丁，要么至少先应用官方提供的最小化回移植补丁。

第二，把缓解措施落在正确的层级。session.upload_progress.enabled=0 要写进 php.ini 或 FPM pool 配置并重启 worker，不要依赖 ini_set() 或 .user.ini；内存与请求体限制优先在网关层统一收口。

第三，把这次事件变成例行机制。安全更新不是一次性动作，建议为 PHP 版本建立订阅式巡检：关注 php.net 官方公告、订阅发行版安全通告、在 CI 中加入版本基线检查。漏洞永远会有下一个，而快速、有序的响应能力才是真正的护城河。

从 10 月 21 日漏洞披露，到 10 月 23 日补充公告，再到 11 月 5 日即将到来的 RC5，PHP 这波操作的节奏感和透明度都可作为开源项目安全治理的参考样本。对使用 PHP 的团队而言，现在最应该做的，就是别让"尽快升级"停留在待办清单里。