Today's PHP security release, and how we're strengthening security
TL;DR · AI 摘要
PHP 8.5.12等版本修复了两个关键RCE漏洞,PHP基金会通过外部审计强化安全体系,开发者需立即升级。
核心要点
- PHP 8.5.12/8.4.27等版本修复CVE-2026-109618和CVE-2026-109619两个高危RCE漏洞
- 内存管理与错误处理模块的漏洞影响所有PHP请求,修复需平衡兼容性与安全性
- PHP基金会通过Quarkslab审计发现漏洞,呼吁依赖组织持续资助安全工作
结构提纲
按章节快速跳转。
PHP 8.5.12等版本修复两个关键RCE漏洞,要求立即升级。
- ·漏洞详情
CVE-2026-109618通过OOM腐败实现RCE,CVE-2026-109619利用陈旧状态触发内存越界。
- ›修复挑战
内存管理模块的漏洞修复需避免兼容性破坏和性能损失。
2024年首次外部审计发现漏洞,PHP基金会推动安全流程改进。
- ›未来方向
呼吁依赖组织持续资助PHP安全工作,建立长期防护机制。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- PHP安全更新
- 漏洞详情
- CVE-2026-109618(OOM腐败)
- CVE-2026-109619(陈旧状态)
- 安全改进
- 首次外部审计(Quarkslab)
- 修复方案权衡分析
- 生态资助呼吁
金句 / Highlights
值得收藏与分享的关键句。
两个漏洞均位于PHP核心模块,影响所有请求处理流程
Quarkslab审计发现漏洞,PHP核心开发者同步发现OOM问题线索
修复方案需在兼容性、性能和生态影响间权衡,无完美解法
今日 PHP 安全更新及 PHP 安全强化措施 —— PHP 基金会 —— 支持、推动和开发 PHP 语言
横幅文字占位符
PHP 基金会
今日 PHP 安全更新及 PHP 安全强化措施
发布日期
2026年10月21日
新闻
安全
今天早些时候,PHP 项目发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 版本。这些更新修复了两个关键漏洞,这些漏洞在特定条件下允许未认证攻击者在运行 PHP 的服务器上执行代码。如果您正在使用 PHP,现在立即更新至关重要。php.net 上的公告包含漏洞的技术细节、攻击路径以及如何在不同系统上更新的说明。
本文的重点不是如何更新,而是这些漏洞是如何被发现和修复的,过去两年间 PHP 安全处理方式发生了哪些变化,以及依赖 PHP 的组织需要如何支持 PHP 安全工作的持续进行。
两个相关的远程代码执行关键漏洞
- CVE-2026-109618 / GHSA-w8hw-w9fx-j79w:通过内存耗尽(OOM)损坏实现的远程代码执行(RCE):如果请求恰好在 PHP 的 memory_limit 达到限制的瞬间到达,PHP 可能会留下部分初始化的内部数据,并在后续将其视为有效数据,导致内存损坏。在使用 Apache 和 mod_php 的环境中,未认证请求可以在任何应用程序代码运行之前触发此问题,默认设置下已成功演示了完整的远程代码执行。通过应用程序级别的代码路径,PHP-FPM 也确认了远程代码执行的可能性。
- CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp:通过过期状态实现的远程代码执行(RCE):如果致命错误发生在错误的位置,内部状态可能会指向属于先前请求的内存。后续由相同工作进程处理的请求可能会使用该已释放的内存。已确认存在使用已释放内存导致工作进程崩溃的情况,报告者还演示了针对运行在 Apache 和 mod_php 环境中的真实应用程序的远程代码执行。
这两个问题都位于几乎所有请求都会涉及的 PHP 组件中:内存管理和错误处理。它们在 PHP 中的核心地位使得这两个漏洞都具有严重性,同时在不破坏兼容性、影响性能或强制第三方扩展生态系统变更的情况下修复它们也极具挑战性。
首次外部安全审计与安全重点提升
2024 年,PHP 进行了多年来的首次外部安全审计。PHP 基金会通过 OSTIF 在主权科技局(Sovereign Tech Agency)资助下组织了此次审计,由 Quarkslab 执行。在修复 Quarkslab 报告的问题时,PHP 基金会聘请的 PHP 核心开发者首次发现了 CVE-2026-109618 后面的 OOM 问题迹象。2024 年,虽然理论上提出了针对 OOM 问题的潜在利用方式,但未发现具体攻击路径,其他具有明确影响的实质性问题也掩盖了这些担忧。
为了解决内存溢出(OOM)问题,PHP安全团队开发了多种竞争性方案,但每种方案都伴随着自身的权衡取舍:破坏向后兼容性、引入新的拒绝服务风险,或需要对大量第三方扩展进行修改,而这些修改似乎难以协调推进。PHP安全团队基于共识机制进行决策,却在这些方案之间难以抉择,并担心做出错误选择可能引发的后果。加之当时尚无已知的远程代码执行路径,且核心开发团队中具备引擎深度知识的成员人数有限,且他们需要承担多项职责,这一决策过程导致修复工作在数月内反复停滞与重启。我们并不回避这一事实:延迟是结构性失败的结果,既源于安全团队的决策流程,也源于其资源的匮乏。此后,安全团队已开始调整其工作流程,相关工作仍在持续进行,以确保决策可通过多数投票达成,并鼓励各方寻求妥协方案。
构建可持续的专业安全组织
过去几个月中,PHP安全工作的组织方式发生了显著变化。2026年5月,PHP基金会成立了生态系统安全团队(Ecosystem Security Team),该团队与PHP安全团队协同工作,负责漏洞分类、协调和加固工作。Volker Dusch作为PHP基金会的AI安全工程师驻场,其工作显著提升了PHP安全团队与基金会之间的沟通与协作。Alexandre Daubois于7月加入PHP基金会,协助PHP安全团队处理漏洞报告和修复工作;Daniel Scherzer则于9月加入,负责加固相关工作。
今年早些时候,我们与Alpha-Omega合作,使用Anthropic的Claude Mythos对PHP进行扫描。但自Mythos扫描之后,我们又引入了其他工具,包括OpenAI的Daybreak Red用于验证报告和利用方式,以及与CI环境匹配的净化构建和复现环境,覆盖PHP支持的所有平台。
PHP基金会将PHP项目纳入了“Patch the Planet”计划。作为该计划的一部分,安全公司Calif于2026年7月30日启动了对PHP的审计。8月11日,Calif的研究员Ryan A报告了一个无条件远程代码执行漏洞,其根本原因与我们在2024年发现的OOM问题相同。同一天,OpenAI也独立报告了相同的根源问题,随后OpenAI于9月18日披露了更多攻击路径,Wiz则于8月24日报告了相关漏洞。最近,Trail of Bits也加入了对PHP的审计工作。来自Calif、OpenAI和Wiz的报告清晰揭示了OOM问题的全面影响,从8月11日起,修复该问题成为PHP基金会所有安全相关团队的首要任务。如果没有基金会的资金支持,就不可能有多个全职人员持续投入此问题的解决,最终甚至需要在周末和全天候工作,以协调和沟通各方参与方。
人工智能辅助研究的兴起也意味着PHP安全团队收到的报告数量大幅增加。如Alexandre Daubois上周在《PHP安全团队如何处理您的报告》中所述,自7月1日起,团队已发布15个CVE漏洞,并处理了超过100份报告,这些报告最终被判定为无效、重复或无法复现。人工智能帮助团队验证报告并归类具有相同根本原因的报告,但所有决策和补丁开发均由人工完成。
协调披露这些漏洞的机制在目标发布日期前两天仍运作良好。
10月20日星期二UTC时间15:00左右,两个CVE编号开始在在线论坛和社交媒体上流传。它们附带了错误的发布时间和错误的CVSS评分10.0(实际评分为9.2),但未泄露任何技术细节。作为回应,PHP项目提前发布了预公告,并于UTC时间19:30发布。它还将原定于UTC时间10月22日14:00的发布时间调整为UTC时间10月21日14:00。由于发行商仍在打包修复程序,立即发布会导致许多用户缺乏便捷的更新途径。将发布时间提前一天是快速行动、给予人们准备时间以及确保所有人拥有简单更新路径之间的最佳折中方案。
由于在UTC时间20:00左右的泄露和预公告,报告该问题的安全公司之一Calif错误地发布了一段视频。该视频展示了他们的概念验证攻击针对多个目标的效果,并泄露了一些额外的(但有限的)漏洞细节。该视频被删除后,其副本很快在社交媒体上开始传播。这段视频加速了各种概念验证攻击代码(PoC)的开发,这些代码在10月21日当天的传播范围进一步扩大。
我们于UTC时间10月20日23:00左右开始向少数关键基础设施提供商提供的缓解建议可能也已泄露。PHP安全团队在泄露后密切监控并检查了出现的概念验证代码,但发布/公开披露时并未发现任何功能性利用代码。
在协调发布前六个多小时的UTC时间10月21日07:41,Chainguard单方面打破禁令,发布了包含修复程序的构建镜像。与其他发行商一样,Chainguard提前收到了补丁,因此其用户可以在漏洞披露的瞬间立即更新。此时任何攻击者都可以在二进制形式中研究该修复程序,而其他所有PHP用户仍在等待发布。这忽视了多方数周来为协调披露所做的努力。
谨慎乐观的展望
今天的发布展示了我们在PHP安全处理方式上的进展。自8月全面理解OOM问题的严重影响以来,安全团队、基金会和发布负责人在所有支持分支上为这一根深蒂固的问题提供了修复方案,各发行版和LTS供应商也提前收到了补丁,使他们的用户能够快速更新。
我们有信心,如果出现需要艰难权衡才能解决的严重漏洞,现在将比以往更快地引起PHP基金会领导层的注意。我们正在调整流程,使领导层能够更有效地引导局势,实现及时解决。我们现在优先采取措施,确保未来报告需要类似复杂修复的漏洞时,能够更快地得到解决。PHP基金会和PHP安全团队在过去几周学到了很多,将继续将这些经验转化为可持续的、可重复的流程。
我们需要您的支持
PHP运行着互联网的很大一部分,包括政府服务、在线商店、银行、媒体网站以及企业日常依赖的大量软件。然而,PHP本身的安全工作仍然依赖于一小群由基金会资助的开发者和少量志愿者的帮助。
如今,工具能够以前所未有的速度发现漏洞,无论是防御者还是攻击者都受益于此,相关报告的数量也将持续增长。然而,工具无法决定如何修复引擎中长期存在的设计决策问题,无法权衡兼容性取舍,也无法审查补丁。做出这些决策需要熟悉整个PHP代码库的资深工程师,而目前这类人才数量远远不足。
PHP基金会使命的核心部分是扩大对PHP代码库有深入理解的工程师群体,并为安全团队提供必要的资源支持。我们只有依靠依赖PHP的各方提供资金才能实现这一目标:
- 以PHP构建产品和服务的公司:请以反映您依赖程度的资助级别支持PHP基金会。
- 提供PHP服务的托管服务商、云平台和发行版厂商,这些服务覆盖数以百万计的用户。
- 使用PHP提供服务的政府和公共机构。德国主权科技局对2024年审计的资助证明了公共投资所能实现的成果,我们需要持续增加此类投资。
资助PHP基金会是确保结构性问题(如内存溢出漏洞)得到可持续解决的最直接方式,避免其演变为紧急事件。立即访问 thephp.foundation/sponsor 成为赞助商,如需讨论更长期的资助承诺,请与我们联系。
感谢
感谢PHP安全团队、志愿者、PHP基金会承包商、发布负责人,以及各发行版和LTS供应商的包维护者,使这些版本的发布成为可能。感谢Calif(特别是Ryan A)、Wiz、OpenAI Codex安全团队(特别是Amy Burnett)、OSTIF和Quarkslab的研究及负责任披露;感谢Alpha-Omega、OpenAI和Anthropic为团队提供工具访问权限并资助部分安全工作;感谢主权科技局资助2024年审计;感谢所有赞助商,正是你们的支持使这项工作得以实现。
- PHP基金会 LinkedIn Mastodon X GitHub
在GitHub上编辑此页面
Matomo
结束Matomo代码