PHP CVE-2026-109618、CVE-2026-109619 漏洞应对指南

PHP 核心引擎在异常终止和请求状态管理过程中存在 CVE-2026-109618、CVE-2026-109619 漏洞，可在无需身份验证的情况下远程执行代码（RCE）。问题源于 PHP 执行引擎自身的内存损坏和释放后使用（Use-After-Free）缺陷，并非 WordPress 或 GNUBOARD 等 Web 应用程序问题。应立即升级到 PHP 8.5.12、8.4.27、8.3.36、8.2.35 等已应用安全补丁的版本，并重启工作进程。

仅更新 Web 应用无法防御的 PHP 引擎漏洞

2026 年 10 月 21 日（UTC），PHP 开发团队公布了两个安全漏洞。根据 CVSS v4.0，风险评分为 9.2。攻击者无需登录，只需发送构造的 HTTP 请求，即可在服务器上执行任意代码。

这些缺陷存在于解析 Web 请求和清理内存的 PHP 核心层。因此，即使及时更新站点 CMS 和插件，只要 PHP 运行时仍是旧版本，系统就会暴露于攻击之下。特别是在 Apache 的 mod_php 默认配置环境中，确认仅通过单个请求即可在 Web 应用代码执行前运行代码。

攻击成功后，入侵者将获得运行 PHP 进程的系统账户权限。虽然不会立即取得 root 权限，但可以在 Web 根目录创建 Webshell，或读取配置文件中的数据库连接信息，从而窃取或篡改内部数据。如果同一服务器上的多个网站共享 PHP-FPM 执行账户，一个站点遭入侵后还可能扩散到服务器上的其他站点。

异常终止引发的内存损坏与释放后使用原理

两个漏洞都源于请求处理过程中出现异常情况时，内存未能被安全清理。但触发条件和内部机制各不相同。

CVE-2026-109618（处理内存超限时发生的内存损坏）：PHP 处理请求时，如果超过允许的内存上限（Out-Of-Memory），会调用 longjmp() 立即中断执行。如果此时内部请求数据结构尚未完全初始化，操作就会中止，不完整状态也不会回滚。之后运行的请求清理（cleanup）例程会将这些未初始化内存误认为正常数据并访问，最终导致内存损坏和远程代码执行。

CVE-2026-109619（引用上一个请求已释放内存的 Use-After-Free）：PHP 内部部分全局状态或错误处理状态会临时指向单个请求拥有的内存区域。当请求因致命错误（fatal error）或内存不足而异常终止时，实际内存可能已经释放，但指向该内存的内部指针引用仍未初始化。在 PHP-FPM 或 mod_php 这类复用工作进程的环境中，同一工作进程接收并处理下一个 HTTP 请求时，会再次读取已经释放的内存区域（Use-After-Free），从而形成代码执行路径。

官方安全公告列出的 CVE-2026-109619 已确认路径包括会话上传进度功能（session.upload_progress）、请求初始化前输出的配置警告，以及 PHP 8.5 的致命错误回溯（fatal_error_backtraces）。不过，公告也指出，即使阻断这些路径，其他变体路径仍然存在。

PHP 各版本补丁状态与运行环境影响范围

低于修复版本的 PHP 8.2～8.5 版本受影响；已停止支持的 8.1 及更低版本不属于 PHP 项目的官方更新范围。运行方式方面，PHP-FPM、mod_php、php-cgi、FrankenPHP、LiteSpeed 等所有处理 Web 请求的安装均属于目标范围，其中官方公告认为 mod_php 的风险最高。Red Hat 将 PHP-FPM 归类为可能通过应用层路径受到条件性影响。

验证环境：截至 2026 年 10 月 22 日，在使用 Remi 软件源的 Linux 服务器环境中，已将 PHP 8.4.26 升级至 8.4.27，并验证 PHP-FPM 工作进程重启及 Web 请求生效情况。

软件包更新与 PHP-FPM 缓解设置的应用步骤

PHP 开发团队表示，仅修改配置无法阻断所有攻击路径，升级到修复版本是唯一且完整的解决方案。更新后，还可以关闭不必要的功能，以减少攻击面。

1. 安装 PHP 软件包更新
   通过操作系统软件包管理器，将当前 PHP 系列升级到修复版本（以 8.4 系列为例，即 8.4.27）。安装后，先在终端确认 CLI 版本。

   php -v

   执行命令后，屏幕会显示类似 PHP 8.4.27 (cli) 的更新版本号和构建日期。但 CLI 版本与实际由 Web 服务器调用的 PHP 进程版本可能不同，因此必须继续执行下一步。

2. 调整 PHP-FPM 设置以减少攻击面（可选的临时缓解措施）
   如果无法立即应用更新，或需要增加防御层，可先备份 php.ini 或 PHP-FPM 池配置文件（例如 /etc/php-fpm.d/www.conf），然后调整以下项目。

   php_admin_value[session.upload_progress.enabled] = Off
   php_admin_value[post_max_size] = 32M
   php_admin_value[upload_max_filesize] = 30M

   禁用 session.upload_progress.enabled 可以阻断已确认的会话攻击路径。调低 post_max_size（不需要文件上传的环境可设为 8M，需要上传的环境可设为 32M 等），可以增加通过大请求诱发内存耗尽的难度。此时应考虑 multipart 附加标头的大小，将 upload_max_filesize 设置得略低于 post_max_size。如果使用 PHP 8.5，还应同时设置 fatal_error_backtraces = 0。

3. 检查 PHP-FPM 配置语法并重启进程
   保存配置后，测试是否存在语法错误，然后重启 PHP-FPM 服务。

   php-fpm -t
   systemctl restart php-fpm

   执行 php-fpm -t 时，如果配置没有问题，屏幕会显示 NOTICE: configuration file ... test is successful。必须重启工作进程，才能结束驻留内存中的旧版本工作进程，并使新补丁和配置生效。

4. 通过 Web 请求确认实际生效版本
   调用 WordPress 的“站点健康（Site Health）”信息页或 Web 服务器集成诊断页面，确认处理 Web 请求的 PHP-FPM 工作进程是否以 8.4.27 等已修复版本响应。如果存在为确认版本而临时创建的诊断 PHP 文件，应在检查后立即删除，避免向外部暴露系统信息。

更新延迟或修改配置产生副作用时的处理方法

第三方软件源（Remi 等）镜像同步延迟，无法下载软件包时

紧急安全补丁发布后，受流量集中或同步延迟影响，第三方软件源（例如 rpms.remirepo.net）可能无法立即查询到更新软件包，或下载速度较慢。官方公告称，由志愿者维护的该软件源在公告当天可能不会发布更新，并建议切换到发行版软件包或源代码构建。

此时可以在软件源配置中直接指定同步完成且速度正常的镜像服务器地址，然后执行更新。即使手动更换镜像，也必须保持 GPG 签名检查（gpgcheck=1）启用，以防软件包被篡改。如果无法使用镜像，可以采用操作系统发行版的官方回移植软件包，或直接编译源代码进行应用。

应用缓解设置后担心内存不足（OOM）或上传被拒绝时

官方公告建议，在无法立即更新时，可将 memory_limit = -1（无限制）作为 CVE-2026-109618 的缓解措施，同时设置容器或 cgroup 内存限制。但在物理内存不足的服务器上解除内存限制，可能导致单个请求耗尽服务器内存，使操作系统的 OOM Killer 强制终止关键守护进程。该设置只能作为更新前的临时措施。升级到修复版本后，建议恢复原有内存限制。

此外，降低 post_max_size（例如从原来的 64MB 调低）前，应先检查站点的文件传输方式。通过管理后台直接上传大型备份文件或插件的站点可能会出现请求被阻断的情况。相反，如果使用 SFTP 或 rsync 传输大文件，或应用本身已限制在 30MB 以下，将 PHP 上传限制降至 32MB 通常不会影响服务。

另外，如果升级 PHP 后 PHP-FPM 工作进程间歇性异常退出，可以检查 OPcache 的 JIT（Just-In-Time）编译设置。JIT 功能（例如 opcache.jit=1255）与本次安全漏洞没有直接关联，但如果过去曾在版本变更时引发稳定性问题，可以在配置文件中设置 opcache.jit=off 将其禁用，以避免冲突。

常见问题

将 WordPress 或插件更新到最新版本后就能解决吗？

不能。该漏洞出现在 PHP 核心引擎中，早于 WordPress 或安全插件的执行阶段。虽然可以通过 Web 应用防火墙（Cloudflare、AWS WAF 等）暂时阻断已知攻击模式，但要从根本上解决问题，必须通过托管服务商或服务器管理员更新服务器上的 PHP 版本。

关闭 session.upload_progress.enabled 后，不更新也安全吗？

不安全。官方公告指出，该设置只能阻断已确认的会话路径，无法阻断其他变体路径。此外，设置不能通过 ini_set() 或 FPM 的 .user.ini 应用，而应放在 php.ini、FPM 池或服务器配置等请求解析前生效的位置，并重启所有工作进程。完整解决方案只有安装补丁。

完成补丁应用后，可以不做额外检查就直接投入运行吗？

更新只能阻止未来的攻击，无法说明系统过去是否已经遭到入侵。完成更新后，仍建议单独检查是否存在先前的入侵迹象。应确认 Web 目录中是否存在近期异常创建或修改的 PHP 文件（如 Webshell），并检查 Web 服务器访问日志和 PHP 错误日志中是否有异常大 POST 请求或反复出现的内存错误记录。

容器或云镜像环境应如何处理？

即使更新了主机服务器上的软件包，容器内部包含的 PHP 运行时也不会自动更新。因此，应使用包含修复版本（8.5.12、8.4.27、8.3.36、8.2.35）的基础镜像重新构建并重新部署容器镜像。

来源

• PHP: Security Advisory (CVE-2026-109618, CVE-2026-109619)
• PHP: PHP 8.4.27 Release Announcement
• PHP: PHP 8 ChangeLog (8.4.27)
• Red Hat Customer Portal - CVE-2026-109618
• Red Hat Customer Portal - CVE-2026-109619
• PHP 원격 코드 실행 취약점 CVE-2026-109618, CVE-2026-109619 대응 및 PHP 8.4.27 업데이트 （韩语）