安全警示:PHP暴露出关键远程代码执行漏洞，立即更新！正文有修复方案

糖果
糖果

网络安全与等保测评

2026年10月22日 09:48
广东

去阅读

PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 修复了两个可能允许未经认证远程代码执行的关键漏洞。强烈建议所有 PHP 用户立即更新。

风险来源：所有服务Web请求的PHP安装，包括PHP-FPM、Apache带mod\_php、php-cgi、FrankenPHP和LiteSpeed。我们认为mod\_php的风险最高，已有验证漏洞利用，未经认证的请求可以在任何应用代码运行前触发攻击。

漏洞：

• 通过OOM损坏

处理RCE，CVE-2026-109618：内存不足处理可能会中断PHP，而内部请求数据仅部分初始化。请求清理时可能会将无效数据视为有效。
* 通过陈旧全局状态

获取RCE，CVE-2026-109619：请求拥有内部状态在其备份存储器被释放后仍可存续。同一工作者处理的后续请求可能会在正常初始化重置前使用该过时状态。

更新方式：

• 更新至 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35。原始码下载可在我们的下载页面。Windows源代码和二进制文件是同一页的。
• Linux发行版和LTS厂商会提前收到补丁，所以请查看你的供应商是否有更新的包。
• PHP 8.1及更早

版本不再接收PHP项目的更新。一些发行版和LTS厂商提供回溯修复，详情请联系你的供应商，或升级到支持的版本。
* 如果您依赖志愿者维护的系统，我们建议您切换到分发包或从源头构建，以便立即应用更新。仓库今天不会有更新。rpms.remirepo.net
* 鉴于这些漏洞的严重性，PHP 安全团队为 PHP 7.4、PHP 8.0 和 PHP 8.1 提供了极少的源码回溯移植，帮助源代码构建者或无法访问 LTS 厂商的用户。

如果无法立即更新：虽然只有更新才是完整的解决方案，但以下措施可以减少特定攻击路径的风险，但并不能保证安装安全。

针对 CVE-2026-109618，官方建议在暂时无法升级时，以管理员配置强制设置 memory_limit=-1，并确认池、目录或应用配置不会重新设置有限的 PHP 内存上限。修改后需要重启所有 PHP 工作进程。

这一建议看起来与通常的资源保护原则相反，但有明确原因：它移除了攻击者可以利用的、可控的 PHP 请求内存限制失败点。它不会阻止底层内存分配失败，也不是完整修复。

同时，解除 PHP 自身的请求内存限制会带来资源耗尽风险，因此必须配合请求限制和外部资源边界。官方建议包括：

• • 不需要文件上传的应用，将 post_max_size 设为 8M；需要上传时，公告给出的建议值为 32M，并保持 upload_max_filesize 小于 post_max_size。
• • 在 Web 服务器或代理层限制解码后的请求体大小、输入字段数量、multipart 分段数量、头部数量和嵌套深度；这些限制也应覆盖没有可用 Content-Length 的请求。
• • 不使用 multipart 表单的应用，可以在前端阻止这类请求进入 PHP。
• • 使用容器或 cgroup 提供可用性边界，并尽可能让资源超限只终止受影响的工作进程；如果限制作用于整个容器或进程组，也可能一起终止主进程和其他工作进程。

不要用 RLIMIT_AS 或 RLIMIT_DATA 替代上述措施。 技术公告指出，它们可能直接造成底层内存分配失败，重新触及存在漏洞的处理路径。容器或 cgroup 限制也不保证彻底避免分配失败，仍不能替代补丁。

会话和回溯配置必须在请求解析前生效

针对 CVE-2026-109619，公告建议关闭会话上传进度；PHP 8.5 还可以关闭致命错误回溯。以适用环境的启动配置为例：

1

;所有受影响分支：阻断已确认的早期会话相关路径

2

session.upload_progress.enabled=0

4

;仅 PHP8.5：阻断已确认的致命错误回溯路径

5

fatal_error_backtraces=0

这些配置必须通过 php.ini、FPM 池或合适的服务器配置，在请求解析之前生效，并重启所有工作进程。不要依赖业务代码中的 ini_set()，也不要依赖 FPM 的 .user.ini 来关闭这条早期会话路径。

此外，应清理请求初始化前会触发诊断的无效或已弃用配置，修复攻击者能够触达的致命错误和执行超时，尤其关注上传、导入、回调和清理流程。只修复正常页面访问时能看到的错误，并不能覆盖所有相关路径。

升级时要确认真正处理请求的运行时已经更新

源码及 Windows 下载入口可见PHP 官方下载页面。使用操作系统软件包、托管运行时或容器镜像的环境，则应跟进对应供应方的修复公告。

官方还在 10 月 21 日公告中特别说明，志愿者维护的 rpms.remirepo.net 当天不会提供更新，并建议相关用户改用发行版软件包或自行编译，以便及时应用补丁。这是当天的仓库供应情况；实际操作时，应核对该仓库后续更新状态。

部署时可以先检查命令行环境：

php -vphp --ini

但这两条命令只说明 CLI 的版本和配置，不能证明 FPM、Apache 模块或容器中的 PHP 已经更新。多版本共存、不同服务使用不同镜像或独立安装目录时，尤其需要分别核对。

实际升级至少应完成以下步骤：

1. 1. 盘点对外处理请求的 PHP 服务、版本、软件包来源和镜像，而不只检查开发机或 CLI。
2. 2. 安装上述修复版本，或确认发行版、LTS 厂商的软件包已经包含对应 CVE 的补丁。
3. 3. 重建并部署使用旧 PHP 的容器镜像，重启或完整滚动替换工作进程，确保没有旧实例继续接收请求。
4. 4. 在实际 Web 运行环境确认版本和配置，检查关键业务路径及错误日志；不要把公开暴露 phpinfo() 页面作为长期验证方式。

修复方案来源于：https://baijiahao.baidu.com/s?id=1879670819705576991