PHP 紧急安全更新：两个 9.2 分漏洞能未登录执行代码，站长今天就升 8.3.36
10 月 21 日深夜，PHP 官方罕见地提前打了一场「预防针」之后又提前交卷：原定北京时间 22 日凌晨发布的紧急安全更新，最终在 21 日就放出。两个漏洞，编号 CVE-2026-109618 与 CVE-2026-109619，研究者给它们起了个外号叫「PHP2Shell」，官方给出的 CVSS v4.0 评分都是 9.2 分——不需要登录、不需要任何账号，攻击者发一个特制请求，就可能在你的服务器上执行任意代码。本站的服务器跑的正是 PHP 8.3 分支，这篇既是新闻，也是本站给自己记的一笔待办。
两个漏洞，坏在同一个地方：内存
按 PHP 官方安全公告的说法，第一枚漏洞（CVE-2026-109618）出在内存耗尽（OOM）处理上：请求处理到一半内存不够时，PHP 会跳出当前上下文，但某些内部数据还没初始化完就被当成有效数据继续用，内存就此被破坏。第二枚（CVE-2026-109619）是「残留的全局状态」：上一个请求留下的内部状态指向已经释放的内存，下一个请求被同一个工作进程接手时又用上了它，属于典型的释放后使用。官方确认的影响范围包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 与 LiteSpeed 等所有对外提供 Web 服务的部署方式，其中 mod_php 风险最高——官方已验证，未经身份验证的请求可以在任何应用代码运行之前就触发攻击。
修复版本对照表，先查自己在哪一档
修复随四个版本一同放出：PHP 8.5.12、8.4.27、8.3.36、8.2.35。你在哪个分支，就升到对应版本：8.4 的升 8.4.27，8.3 的升 8.3.36（本站就在这一档），8.2 的升 8.2.35。还在用 8.1 及更老版本的用户要特别注意：官方不再为这些分支发布常规安全版本，只能寄希望于发行版或长期支持厂商的回移植补丁——说白了，是时候认真考虑升到受支持的分支了。官方的原话很直白：没有完整的缓解办法，升级是唯一安全的选择。唯一能临时挡一下的是第二枚漏洞的一条已确认路径：关掉 session.upload_progress 并重启所有工作进程可以堵住会话上传进度这条路，但堵不住其他变体，不能代替升级。另外别忘了：升完级要重启 PHP-FPM 或 Apache，长驻的工作进程不重启，新代码不会生效。
站长判断
这次事件最值得普通站长学的一课，不是漏洞本身有多吓人，而是披露节奏被打乱之后，防御方的时间窗口被压缩到了几个小时：漏洞细节在正式发布前一天就开始流传，多家安全厂商在官方补丁落地前就观测到了真实的攻击流量。对用 WordPress 这类 PHP 程序建站的人来说，正确动作只有三步：今天就查版本、升到修复版、重启服务；然后把服务器上重要的账号口令顺手轮换一遍——本站的在线密码生成器就是干这个的，生成完记得存进密码管理器。把「等周末再维护」留给别的更新，这次别等。
和昨天那篇 OpenBSD 一起看
有意思的是，就在同一周，OpenBSD 8.0 刚刚发布，那个系统三十年如一日把「默认安全、攻击面小」放在功能前面（本站昨天刚聊过）。PHP 这次的两个漏洞恰恰说明：软件规模越大、长驻进程活得越久，内存里残留的状态就越危险。普通用户改变不了语言运行时的设计，但可以养成一个习惯——运行环境的小版本更新，尤其是标着 security release 的，一个都不要拖。本站此前写的Python 3.15 也讲过同样的道理：跟上官方支持的版本节奏，本身就是最便宜的安全措施。
相关阅读
· OpenBSD 8.0 发布：虚拟机拉到 64 核，这个「慢系统」补上了两块短板
· Python 3.15 来了：懒加载和 UTF-8 默认，冲着这两点就值得升
信息来源：PHP 官方安全公告与 8.2.35 发布说明（php.net，2026-10-21）；文中判断为本站观点。
发表评论