补丁来了！PHP 9.2 分严重漏洞「php2shell」今晚修好，所有版本都要升，赶快更新！

几个小时前刚和大家说了《PHP 爆发近几年最严重的安全漏洞，9.2 分，能直接拿下服务器权限那种，WordPress 站点都要注意了！》，当时还是「细节已经泄漏、补丁还没到」的那个最难受的状态。

现在补丁来了，北京时间今晚 10 点整，PHP 官方准时发布。

这次不是一个分支，是四个受支持分支一次到齐：8.5.12、8.4.27、8.3.36、8.2.35。换句话说，从这一刻起，你的服务器安不安全，就只取决于你有没有去升。

跑 Web 的 PHP 都有风险！！！

之前大家都是靠泄漏出来的信息在猜，现在官方把话说死了。

第一，跑 Web 的 PHP 全在射程内。 官方原话是所有处理 Web 请求的 PHP 安装都受影响，包括 PHP-FPM、Apache 加 mod_php、php-cgi、FrankenPHP 和 LiteSpeed。

第二，mod_php 最危险，而且已经有能跑的。 官方明确说他们认为 mod_php 的风险最高，存在已演示的利用程序（exploit）：一个未授权的请求，可以在任何应用代码运行之前触发攻击。

这句话其实把上一篇文章里那句「WordPress 安全插件没用」彻底坐实了。插件靠 auto_prepend_file 加载，等它跑起来，仗已经打完了。

两个漏洞的机制和细节

CVE-2026-109618：通过内存耗尽（OOM）损坏实现 RCE，内存耗尽的处理，可能在 PHP 的内部请求数据只初始化了一部分的时候把它打断。随后的请求清理，就可能把这份无效数据当成有效数据来用。

https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w

CVE-2026-109619：通过残留的全局状态实现 RCE，属于某个请求的内部状态，在它背后那块内存被释放之后还可能活着。同一个 worker 处理的下一个请求，可能在正常初始化把它重置掉之前，就用上了这份残留状态。

https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp

第二条要特别留意：它意味着打补丁之前的每一次请求，都可能在给下一次请求埋雷。 所以升级完重启 worker 这件事，不是仪式感，是必须做的动作。

怎么更新？

8.2 以及以上版本，更新到 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35 即可，源码和 Windows 二进制都在 php.net 的下载页：

https://www.php.net/downloads.php?source=Y

Linux 发行版和 LTS 厂商提前拿到了补丁，直接问你的厂商要更新包就行。

考虑到这两个漏洞的严重程度，PHP 安全团队为 PHP 7.4、PHP 8.0 和 PHP 8.1 提供了最小化的源码 backport，专门给那些自己从源码构建、或者拿不到 LTS 厂商支持的人。

注意「最小化」这三个字。它不是一份完整的 8.1.37，只是把这两个 CVE 修掉的最小补丁集，你得自己往源码上打、自己编译。共享主机的用户拿不到这个，还是得催服务商。

如果你用的是志愿者维护的 rpms.remirepo.net，官方这次直接劝退了，原话是强烈建议改用发行版自带的包或者从源码构建，因为这个仓库今天不会有更新。用 remi 的同学，今晚得自己想办法。

暂时升不了级，官方给的权宜之计

如果你的机器今晚动不了，官方给了一份缓解清单。但公告里把话说得很明白：只有更新才是完整的解决方案，下面这些只能降低特定攻击路径的暴露面，不会让你的安装变得安全。

针对 CVE-2026-109618（OOM 损坏）

设 memory_limit=-1，最好用应用改不动的方式，比如 FPM pool 或 Apache 配置里的 php_admin_value，并且检查一遍，确认没有哪个 pool、目录或应用设置又把有限的数值塞回去。这消除了「PHP 内存限制被触发」这个可控的失败点，但底层真正的分配失败还是可能走到漏洞路径上。

设一个较低的 post_max_size。不需要文件上传的应用，设 post_max_size = 8M。必须上传文件的，设 post_max_size = 32M。保持 upload_max_filesize 低于 post_max_size。同时考虑在 Web 服务器或代理层强制限制这些维度：解码后的请求大小、输入字段数量、multipart 分段数量、header 数量、嵌套深度。这些限制还必须覆盖那些没有可用 Content-Length 的请求。

用容器或 cgroup 限制作为可用性边界，最好是「只杀掉受影响的那个 worker」这种策略。不要用 RLIMIT_AS 或 RLIMIT_DATA 来替代，因为它们反而会造成那个有问题的分配失败。

针对 CVE-2026-109619（残留全局状态）

设 session.upload_progress.enabled=0，然后重启每一个 worker。 用 php.ini、FPM pool 或者服务器配置，保证它在请求解析之前就生效。不要依赖 ini_set() 或 FPM 的 .user.ini。这能挡住已确认的 session 路径，但挡不住其他变体。

在 PHP 8.5 上，设 fatal_error_backtraces=0，然后重启每一个 worker。 这只挡住已确认的致命错误回溯路径。

移除那些按请求生效、会在初始化之前输出诊断信息的无效或废弃设置。 用 error_reporting、display_errors 或者 @ 把诊断信息藏起来是没有用的。

修复攻击者可以触发的致命错误和执行超时，包括回调、上传或导入处理、以及清理过程中的失败。

WordPress 站点具体该做什么

那 WordPress 站点具体该做什么？

先看版本，后台「工具 → 站点健康 → 信息」里就有 PHP 版本，或者跑 wp cli 看。如果是 VPS / 独立服务器，按上面升就是了；如果是共享主机，你能做的只有一件事，催服务商确认装的是修复版本，别只问「有没有升 PHP」，要问「是不是 8.3.36 / 8.2.35 这个修复版本」。升不了的话，把 session.upload_progress.enabled=0 这条让服务商加上，或者自己在站点根目录放 .user.ini。