2026年10月21日，php官方发布安全更新，修复编号cve-2026-109618和cve-2026-109619的两个核心漏洞。两类漏洞都和内存异常状态相关，可被利用实现未认证远程代码执行。因为补丁修改的是php运行时底层，升级wordpress、laravel这类业务项目的代码或composer依赖，完全不能替代php本身的版本更新。
两个漏洞的差异与不同SAPI的风险边界
查看CVE-2026-109618官方公告可知，漏洞触发原因是PHP执行过程中内存耗尽，程序提前跳出还没完成初始化的操作，后续清理逻辑访问了无效的内存状态。不同SAPI（PHP对接Web服务器的运行模式）对启动失败的处理逻辑不一样，mod_php已经在默认环境下拿到完整利用演示，而针对FPM的风险目前仅完成源码层面的应用可达路径分析，不能直接认定两种运行模式的利用条件完全一致。
CVE-2026-109619官方公告的触发点是跨请求的悬空指针：工作进程处理完一个请求后，部分全局字段仍然指向已经被释放的请求内存，下一个新请求还没完成全量初始化时就访问这些字段，就会触发释放后使用漏洞。这项漏洞的FPM利用路径与具体应用操作有关，需要与109618的OOM触发路径分别理解。
不能仅凭自己使用FPM、调用过session_start、部署了特定CMS就判定自己的业务不受影响，最终风险要结合当前PHP版本、运行模式、加载扩展和实际请求处理路径综合判断。
官方明确的修复版本范围
PHP官方安全公告列出了上游直接发布的四个修复版本，后续同分支的常规安全更新也建议跟进安装。
立即学习“PHP免费学习笔记（深入）”；
| 分支 | 此次上游修复版本 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Linux发行版普遍会把上游安全补丁回移到当前维护的旧版本号分支，比如Ubuntu 24.04的修复版本号是8.3.6-0ubuntu0.24.04.13，来自Ubuntu USN-8948-1安全公告。不能直接拿“8.3.6小于上游修复版8.3.36”判定这个包没打补丁，也不能用Ubuntu的包版本规则套用到其他来源的PHP安装包上。
为什么不能直接抄几行补丁代替完整升级
PHP 8.2分支对应的修复提交是01a40e89：Avoid state corruption via bailout，提交位于8.2.34到8.2.35的迭代区间内，修改范围覆盖内存分配器、执行器、Session模块、OPcache和多个扩展，配套包含完整的回归测试用例，你也可以直接查看完整补丁文件查看全部代码变动。
这类底层状态修复要保证引擎全模块逻辑一致，不可能从diff里摘几行直接拼到业务代码或者其他PHP分支里。自行编译源码的用户要直接基于官方发布的完整修复版重新编译，保持原有编译选项不变，提前做好扩展兼容性测试；用系统软件包管理安装PHP的用户，优先安装发行商官方推送的安全更新包。
升级前先区分不同运行环境的PHP版本
<code class="bash"># 当前命令行 PHP 的版本与配置路径 php -v php --ini # 查看 FPM 启动信息，找出实际安装路径 ps -ef | grep '[p]hp-fpm' # 源码安装示例：按真实路径替换 /usr/local/php/sbin/php-fpm -v /usr/local/php/sbin/php-fpm -t</code>
命令行模式CLI加载的php.ini配置，和FPM用的配置不一定是同一份。用面板、多版本PHP站点或者容器部署的环境，往往各自维护一套独立的PHP二进制文件。如果PHP是手动编译安装在/usr/local/php路径下，直接执行系统包管理器的升级命令，根本不会改动这个路径下的文件。要先整理清楚每个站点对应的FPM池、监听地址和PHP二进制启动路径，再选对应的升级方式。
Ubuntu 24.04官方PHP8.3 FPM包升级步骤
下面的操作命令仅适用于已经安装Ubuntu 24.04官方源PHP8.3 FPM包的主机。操作前先查看可升级的候选包，模拟升级确认来源和版本没问题，再执行正式安装。手动编译安装、第三方源Sury包、容器镜像和其他Linux发行版要走自己对应的升级流程。
<code class="bash">sudo apt-get update
apt-cache policy php8.3-fpm php8.3-cli
sudo apt-get --simulate install --only-upgrade php8.3-fpm php8.3-cli
# 确认候选包包含 USN-8948-1 修复后，再执行
sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli
sudo /usr/sbin/php-fpm8.3 -t
# 仅在配置检查成功后重启该 FPM 服务，涉及短暂服务切换
sudo systemctl restart php8.3-fpm
dpkg-query -W -f='${Package} ${Version}\n' php8.3-fpm php8.3-cli</code>
如果你用的是Apache mod_php模式，实际运行的PHP包是libapache2-mod-php8.3，不能只升级FPM包就完事。用容器部署的业务，应更新镜像并替换旧容器，避免只在运行中的容器临时改包。同一台主机上安装的其他PHP大版本分支，也要单独检查升级。安装完更新包之后，已经启动的旧工作进程不会自动加载新的二进制文件，必须手动重启对应服务。
暂时无法升级时的临时配置缓解方案
关闭Session上传进度功能，可以阻断目前已公开的部分漏洞利用路径。下面的配置示例适合不需要大文件上传的业务，配置必须在Web请求解析前生效，还要检查FPM池和站点配置是否覆盖了这些设置，写完之后要重启所有相关的PHP工作进程才能生效。
<code class="ini">; 临时降低部分风险，不是完整修复 session.upload_progress.enabled = Off post_max_size = 8M upload_max_filesize = 6M</code>
确实需要保留文件上传功能的业务，PHP官方建议把post_max_size设为32M，同时单文件上传限制要低于请求体总限制。还要在入口层校验解码后的请求体大小、字段数量、multipart分段数和请求头数量，只根据Content-Length头判断，或只设置Nginx的单项请求体限制，都不足以覆盖其他内存消耗来源。
运行PHP 8.5的环境，官方还建议临时关闭fatal_error_backtraces配置，阻断对应的公开利用路径。这个配置只需要加到支持该指令的8.5版本环境里。
<code class="ini">; 仅用于 PHP 8.5 的对应临时缓解 fatal_error_backtraces = Off</code>
针对请求早期处理阶段的缓解，不能仅依赖业务脚本中的ini_set()，或初始化后才加载的FPM .user.ini；相关设置需要提前生效。关于PHP配置的生效规则可以参考PHP官方配置修改说明和FPM官方配置文档。
各类临时缓解措施的边界限制
PHP官方把设置memory_limit=-1（完全取消每请求内存上限）列为CVE-2026-109618的主要配置缓解手段之一，但即便开了这个配置，底层内存分配失败的场景下程序还是可能走到危险触发路径。同时这个配置会完全取消PHP的每请求内存限制，应结合容器或cgroup等外部可用性边界评估；不要用RLIMIT_AS或RLIMIT_DATA代替，这些限制可能触发危险的底层分配失败路径，不能在业务保留原有内存上限的情况下声称已经用了这个方案，也不能把它当成无条件推荐的生产环境优化项。
WAF规则、请求频率限制、关闭部分非必要功能这类手段，都只能减少漏洞暴露的可能性，完全不能替代引擎底层的官方补丁。PHP官方还在代码仓库提供了不受维护的旧版本回移补丁分支，分别对应7.4、8.0、8.1，这并不代表这些旧分支恢复了官方常规维护，不能由此推断PHP 5.6也存在通用的上游修复包。还在使用旧版本的用户，要么找到对应维护供应商提供的明确补丁记录，要么尽快迁移到仍在官方支持的PHP版本分支。
