PHP 紧急更新：8.2.35 至 8.5.12 修复两个严重核心 RCE 漏洞
PHP 发布了一次计划外安全更新，修复语言核心中两个可被用于未认证远程代码执行的严重 use-after-free 漏洞，CVSS v4.0 评分均为 9.2。已修复版本为今日发布的 PHP 8.5.12、8.4.27、8.3.36 与 8.2.35，见项目发布存档。长期无人维护的 7.4、8.0 和 8.1 分支仅有最小的源码回移，放在 GitHub 上——官方不为它们提供二进制包。
此次发布之前是一段异常混乱的提前泄露期。10 月 20 日，项目方宣布将在今天 14:00 UTC 进行紧急发布，但未指明受影响版本与函数；据 OX Security 记录，在补丁发布之前就有漏洞利用工具的截图流传，项目方自己也警告：在这一窗口期流通的概念验证代码往往伪装着恶意软件。如今补丁与公告均已公开，技术图景比预热炒作所暗示的更清晰。从内存耗尽到代码执行的路径
CVE-2026-109618（编号 GHSA-w8hw-w9fx-j79w）滥用了 PHP 处理内存耗尽的方式。当一次分配失败时，引擎用 longjmp() 将请求展开回退——如果这发生在请求内存仅部分初始化之时，收尾阶段随后会读取或在无效状态的内存上分支。公告描述了一族让这可以从普通 HTTP 请求触达的分配压力把戏：没有可用 content-length、从 post_max_size 之下溜过去的 multipart 请求体；塞满数千个头部、其在内存中的表示远超线上体积的分段；以及从不计入 max_file_uploads 却分配元数据数组的空文件控件。 Apache 的 mod_php SAPI 已被确认可被利用：研究人员在默认 prefork 配置上通过普通 HTTP 验证了以 web worker 账户身份进行的未认证远程代码执行——攻击复杂度高，且可能需要多次尝试。PHP-FPM 被认为可通过应用特有的分配路径受影响，FrankenPHP 与 LiteSpeed 大概率同病相怜。补丁将原始 longjmp 替换为在 VM 下一个安全点的软性内存耗尽陷阱，外加一记直接终止 worker 的硬失败。worker 进程中的陈旧全局状态
CVE-2026-109619（GHSA-6wmf-4rv5-p3rp）是更安静的那个：worker 进程携带着可能指向单次请求所拥有内存的全局状态——错误处理程序、会话数据、对象与扩展的记账信息。如果致命错误、内存耗尽中止或迟来的诊断写入了这类状态，而在请求内存被释放前没有任何东西将其重置，worker 的全局变量便悬空了。在新请求初始化之前碰到它们的任何代码，读到的都是已释放的内存。 两条生产路径已获确认：PHP 8.5 新增的致命错误回溯（mod_php 下），以及 session upload progress 机制（mod_php 与 FPM 下）。生产者与消费者必须落在同一个 worker 进程上，这让拥有大量 worker 的 FPM 池更难命中——但并非不可能。经过策略性布局的堆排列可以产生完整的远程代码执行（RCE）。—— PHP 安全公告，GHSA-6wmf-4rv5-p3rp
管理员现在应该做什么
更新是唯一完整的缓解措施，而且这不是"打完补丁就完事"：两份公告都强调升级后必须重启所有 PHP worker，因为陈旧状态可能在长寿命进程中存活。受支持分支有发行二进制；钉死在 EOL 分支上的站点必须自行套用源码回移。- 升级到 8.2.35、8.3.36、8.4.27 或 8.5.12（或为 7.4/8.0/8.1 应用 GitHub 回移），然后重启每一个 worker 进程。
- 今天无法升级的：设置 session.upload_progress.enabled=0，PHP 8.5 上再设 fatal_error_backtraces=0，并重启 worker。
- 针对 OOM 漏洞，集中强制 memory_limit=-1，并核实没有任何 pool 或 .htaccess 覆写恢复有限限制。
- 保持保守的 post_max_size，若应用不用 multipart 请求则在最前端拦截之，并限制输入变量、头部与上传数量。
- 使用容器或 cgroup 内存限制，而不是 RLIMIT_AS 或 RLIMIT_DATA——公告明确警告 RLIMIT 机制会把分配失败推向易受攻击的路径。
- 可选：用 pm.max_requests 限制 worker 回收，缩短状态残留窗口。