今天早些时候，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损坏进行的远程代码执行（内存溢出）：如果请求在错误的时刻达到PHP的memory_limit，PHP可能会留下部分初始化的内部数据，后来将其视为有效，导致内存损坏。在使用mod_php的Apache上，未经身份验证的请求可以在任何应用程序代码运行之前触发此情况，并且在默认设置下演示了完全的远程代码执行。在PHP-FPM上通过应用程序级代码路径也确认了远程代码执行。CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp : 通过过时状态进行的远程代码执行：在错误的时刻发生的致命错误可能会留下指向属于先前请求的内存的内部状态。随后，由同一工作线程处理的后续请求可能会使用该已释放的内存。确认了使用后释放和工作线程崩溃，报告者在运行mod_php的Apache上的真实应用程序中展示了远程代码执行。这两个问题出现在几乎每个请求都会接触到的PHP部分：内存管理和错误处理。它们在PHP中的核心地位使这两个漏洞变得严重，同时也使修复这些漏洞变得非常困难，因为这可能会破坏兼容性，影响性能，或者迫使第三方扩展的庞大生态系统进行变化。2024年的第一次外部审计与增强的安全关注在2024年，PHP经历了多年来首次外部安全审计。PHP基金会获得了来自主权技术机构的资金，通过OSTIF组织此次审计，并由Quarkslab进行。 在修复Quarkslab报告的其中一个问题时，PHP基金会聘请的核心开发者发现了CVE-2026-109618背后OOM问题的第一个迹象。在2024年，理论上提出了OOM问题的潜在利用，但没有发现具体的攻击向量，而其他具有明显影响的具体问题掩盖了这些担忧。为了解决OOM问题，PHP安全团队开发了几种竞争性的方法，但每种方法都有自己的权衡：向后兼容性破坏、新的拒绝服务潜力，或要求对许多第三方扩展进行更改，这似乎是无法协调整的。PHP安全团队在达成共识的操作中艰难地在这些方法之间进行选择，并担心错误选择的后果。结合缺乏已知的远程代码执行路径和只有少数核心开发者拥有必要深入知识并承担诸多责任，这一决策过程导致修复的工作在数月内停滞和反复重启。我们不会假装相反：延迟是结构性的失败，由安全团队的决策过程和资源不足造成。安全团队自那时起已开始改变其流程，这项工作仍在继续，以便能够通过多数决定，并鼓励妥协。建立一个可持续的专业安全组织在过去几个月中，PHP安全工作的组织方式发生了显著变化。2026年5月，PHP基金会创建了生态系统安全团队，该团队与PHP安全团队合作，进行分类、协调和加强工作。Volker Dusch作为PHP基金会的AI安全工程师驻驻人员，显著改善了PHP安全团队与基金会之间的沟通与协作。Alexandre Daubois于7月加入PHP基金会，帮助PHP安全团队进行安全报告的分类、处理和修复，Daniel Scherzer于9月加入，负责加强工作。今年早些时候，我们与Alpha-Omega合作，利用Anthropic的Claude Mythos扫描PHP。但自Mythos扫描以来，我们还添加了其他工具，包括OpenAI的Daybreak Red，用于验证报告和漏洞，以及与我们在每个PHP支持的平台上的CI匹配的清理构建和再现环境。PHP基金会将PHP项目纳入了Patch the Planet计划，作为其中的一部分，安全公司Calif于2026年7月30日开始对PHP进行审核。2026年8月11日，Calif的研究人员Ryan A首次报告了与我们在2024年发现的OOM问题相同根本原因的无条件远程代码执行。OpenAI在同一天独立报告了相同的根本原因，随后OpenAI进一步提出了其他攻击向量。