【文章简介】本文围绕 PHP 两个高危远程代码执行RCE漏洞展开分析漏洞成因、影响范围、风险场景及修复方案并结合实际运维场景介绍环境排查与修复验证方法。【适用读者】网络安全从业者、安全运维及渗透测试人员PHP 开发人员、后端工程师负责服务器运维、漏洞管理及安全应急的技术人员【阅读收获】读完本文你将了解两个漏洞的核心原理掌握 PHP 运行环境的排查思路以及高危漏洞从风险确认到修复验证的基本流程。一、漏洞背景2026年10月21日PHP官方发布安全公告披露并修复了两个可能导致远程代码执行RCE的严重安全漏洞。两个漏洞的CVSS v4.0评分均为9.2部分攻击路径无需身份认证。本次漏洞涉及PHP运行时内部的内存管理和请求状态处理机制。由于PHP广泛应用于网站、业务后台及API服务一旦相关运行环境受到影响风险可能不局限于单个应用程序。本文将从漏洞原理、影响范围、排查方法和修复方案几个方面进行分析。1. 漏洞基本信息项目CVE-2026-109618CVE-2026-109619漏洞名称RCE via OOM corruptionRCE via stale global state核心问题内存耗尽异常导致内部状态不一致过期全局状态导致释放后使用主要风险远程代码执行远程代码执行CVSS v4.09.29.2修复方式升级PHP升级PHP官方公告PHP官方安全公告CVE-2026-109618技术公告CVE-2026-109619技术公告二、漏洞原理分析理解这两个漏洞需要先了解PHP处理Web请求时的基本流程。一个典型的PHP请求会经历以下阶段Web服务器接收HTTP请求。PHP运行时初始化请求上下文及内部数据。PHP解析请求并执行应用程序代码。请求结束后清理请求期间创建的状态和资源。工作进程根据运行模式继续处理后续请求。如果初始化、异常处理或资源释放过程中出现状态不一致就可能导致程序访问无效内存进一步引发安全问题。2.1 CVE-2026-109618OOM异常处理导致的远程代码执行OOM是Out of Memory的缩写表示程序申请内存时无法获得所需资源。PHP在处理内存分配失败时会通过异常中断机制退出当前执行上下文。在特定执行路径下如果请求内部数据尚未完成初始化异常中断就可能使运行时进入不一致状态。随后请求结束时的清理逻辑可能将这些无效数据当作正常数据处理导致内存安全问题并可能最终形成远程代码执行。可以将其简化为以下流程Web请求进入PHP运行时 | v 初始化请求内部数据 | v 发生内存分配失败OOM | v 当前执行流程被中断 | v 请求内部状态未完成初始化 | v 清理逻辑访问异常状态 | v 可能引发内存破坏及远程代码执行这只是对漏洞机制的概念性说明并非实际利用代码。根据PHP官方公告攻击者可以利用特定的请求处理路径触发相关问题。尤其值得注意的是某些multipart请求可能绕过预期的请求体大小限制使程序在请求处理过程中进入异常状态。这说明单纯依赖PHP自身的内存限制并不能保证所有内存分配失败路径都得到安全处理。2.2 CVE-2026-109619过期全局状态与Use-After-Free第二个漏洞涉及PHP工作进程中的内部状态管理。PHP运行时维护着错误处理、会话、对象和扩展等多种状态。其中一部分状态与当前请求所使用的内存有关因此必须在释放请求内存前正确重置。如果请求结束时没有完成必要的状态清理相关引用就可能指向已经释放的内存区域。这类问题被称为Use-After-Free简称UAF即释放后使用。漏洞形成过程可以简化为工作进程处理请求A | v 创建请求相关的内部状态 | v 异常处理或清理流程未完成状态重置 | v 请求内存被释放 | v 部分内部状态仍然残留 | v 工作进程处理请求B | v 初始化完成前访问过期状态 | v 可能产生内存安全问题及远程代码执行这里的关键在于请求内存的生命周期已经结束但某些内部状态仍然保留着指向该内存的引用。当后续处理逻辑访问这些引用时就可能触发UAF问题。PHP官方公告指出致命错误、内存耗尽、警告信息以及部分会话处理路径都可能与状态未正确重置有关。需要注意工作进程复用不意味着不同用户的业务数据必然互相可见。这里讨论的是PHP运行时内部状态的生命周期问题。2.3 两个漏洞的区别这两个漏洞的共同点是PHP运行时内部状态管理存在缺陷但问题的切入点不同。CVE-2026-109618 重点在于内存耗尽异常导致初始化过程被中断后续清理逻辑可能处理无效状态。CVE-2026-109619 重点在于请求结束后某些内部状态未被正确重置后续操作可能访问已释放的内存。它们反映出一个重要的底层安全原则异常处理流程必须与正常执行流程一样严格维护内存有效性、对象生命周期和内部状态的一致性。三、影响范围与风险分析PHP官方明确指出所有用于处理Web请求的PHP安装都需要关注本次漏洞包括PHP-FPM、Apache mod_php、php-cgi、FrankenPHP和LiteSpeed等部署方式。官方认为Apache mod_php的风险尤其高因为已确认存在无需认证、可在应用程序代码执行前触发攻击的路径。重点排查以下场景使用PHP构建的互联网网站及业务后台。通过Nginx或Apache配合PHP-FPM运行的业务系统。使用Apache mod_php的旧系统。使用php-cgi等方式运行的应用。基于容器部署、但仍使用受影响PHP版本的业务。需要强调使用PHP不代表系统已经被入侵是否存在可利用风险还取决于实际版本、运行模式和触发条件。四、如何排查PHP环境是否受影响4.1 查看PHP版本在Linux服务器执行php -v查看当前命令行PHP版本。也可以执行php --ini查看当前命令行环境使用的配置文件。需要注意命令行PHP与Web服务实际使用的PHP可能不是同一套安装因此这两条命令只能作为初步检查。4.2 排查Web服务实际运行版本对于Nginx与PHP-FPM组合需要进一步确认Nginx配置中的fastcgi_pass指向哪里。PHP-FPM实际使用的可执行文件路径。PHP-FPM进程加载的版本及配置。是否存在多套PHP安装或多个容器实例。对于Apache环境应确认PHP使用的是mod_php、CGI还是其他运行方式。容器化部署还需要检查实际运行的容器和镜像内容而不能仅根据镜像名称判断安全状态。4.3 核对操作系统软件包部分Linux发行版可能通过回移补丁修复漏洞软件包版本号不一定与PHP上游版本完全一致。因此除检查PHP版本外还应核对对应操作系统的安全公告及软件包修复状态避免误判。五、如何修复漏洞5.1 官方修复版本PHP官方公布的修复版本如下。PHP分支修复版本PHP 8.58.5.12PHP 8.48.4.27PHP 8.38.3.36PHP 8.28.2.35建议优先升级至对应分支的官方修复版本并在升级前完成兼容性测试、数据备份和变更评估。对于无法立即升级的生产系统应根据官方公告实施临时风险控制措施。但官方明确指出这些措施无法完全替代升级。5.2 暂时无法升级时的风险控制针对CV​​E-2026-109618可以评估以下措施合理限制请求体大小、multipart字段数量及嵌套深度。在Web服务器或代理层实施请求大小限制。根据官方建议评估PHP内存限制的配置方式。通过容器或cgroup等机制限制单个工作进程异常对系统可用性的影响。官方建议在适用环境中设置memory_limit-1以避免通过可控的PHP内存限制触发特定攻击路径。但这会取消PHP自身的内存上限可能增加资源耗尽风险必须结合系统级资源限制谨慎评估不能直接在生产环境盲目使用。针对CVE-2026-109619可以评估关闭会话上传进度功能session.upload_progress.enabled0PHP 8.5还可以根据官方建议评估fatal_error_backtraces0这些配置只针对已确认的部分攻击路径不代表漏洞已经彻底修复。具体生效方式、配置位置和工作进程重启要求应以官方公告为准。如果无法及时修复且系统直接暴露于互联网应考虑临时限制访问必要时暂停受影响的服务。六、修复后如何验证漏洞处置不能止步于执行升级命令还需要确认修复是否真正生效。检查项验证内容PHP版本命令行与Web实际运行版本均已核实软件包状态已安装官方或发行版提供的修复版本工作进程已重新加载或重启确保新版本生效资产覆盖所有PHP实例均已纳入排查业务验证核心功能及相关扩展运行正常安全监测检查异常请求、进程、文件变化及其他可疑迹象对于已经暴露在互联网的系统还应检查历史访问日志和系统状态。修复完成只能说明软件漏洞处置取得进展并不能证明此前没有发生入侵。七、技术启示本次PHP漏洞事件至少带来三个值得重视的经验。第一安全风险不只存在于业务代码中。即使应用层具有身份认证、权限控制和输入校验底层运行时仍可能存在独立的安全缺陷。因此安全评估应覆盖应用代码、运行时、依赖组件和基础设施。第二资产清单直接影响漏洞响应速度。企业应能够快速识别哪些服务器、容器和业务系统正在使用PHP哪些直接暴露在互联网以及哪些系统无法立即升级。如果资产信息不完整漏洞应急就可能陷入逐台寻找、逐个确认的被动局面。第三修复必须形成可验证的闭环。漏洞治理应包括发现、确认、修复、验证和复查。每一项处置都应有明确结果和记录而不是只在工单中填写“已升级”。八、总结CVE-2026-109618和CVE-2026-109619是PHP运行时层面的两个严重安全漏洞分别涉及OOM异常处理和过期内部状态访问问题均可能导致远程代码执行。对于开发和安全运维人员建议优先完成以下工作盘点所有PHP运行环境重点关注互联网暴露资产。核实实际运行版本及部署方式。尽快安装官方或对应发行版提供的修复版本。对暂时无法升级的系统实施经评估的临时风险控制措施。通过版本、进程、资产清单和日志检查形成修复闭环。安全工作的重点不仅是发现漏洞更是确保受影响资产被完整识别、风险得到及时处理并且修复结果能够被验证。参考资料PHP官方安全公告2026年10月21日CVE-2026-109618RCE via OOM corruptionCVE-2026-109619RCE via stale global statePHP官方版本发布记录本文用于网络安全技术交流与防御性排查。具体影响范围、临时缓解措施和修复状态请以PHP官方公告及对应操作系统发行版的安全公告为准。推荐阅读AI编程时代的两大隐忧代码失控与技术生态趋同大模型套壳滥用与AI智能体带来的新型安全风险及企业防护思考复合型社会工程威胁分析社交诱饵引发的多终端数据窃取风险与防御实践2026网络安全管理者能力模型升级告别技术堆砌走向战略与业务韧性治理自主AI Agent全自动化入侵从Hugging Face安全事件看AI攻击与传统防护失效危机AI安全攻防重心全面迁移从提示词防护走向智能体自主操作风险治理Claude Code后门隐患深度拆解与AI供应链安全治理方案CVE-2026-0007 Android界面覆盖劫持提权漏洞深度解析与全维度防护方案