PHP 基金会在一篇事后说明文章中承认，刚刚完成修补的关键漏洞，其征兆早在 2024 年就已被基金会开发者看到，但由于当时没有找到具体攻击路径，加上多套修法各有代价，补丁推进近两年都没有定案。
基金会称，这次延误属于「结构性失败」，问题出在安全团队的决策流程和资源不足。不过文中也强调，2024 年时团队掌握的仍只是理论上的利用可能，并未确认可被实际利用的路径，这与明知可远程执行代码却放着不修并不相同。
漏洞征兆来自另一项问题的修复过程
基金会表示，最早的征兆出现在核心开发者修复 Quarkslab 审计回报的另一项问题时。这个内存问题本身并不在审计报告条目中。资安公司 Calif 的说法也一致：当时没有证实可利用，因此没有进入修补流程。
到 2025 年 4 月审计结果公布时，基金会对外写的是「PHP 开发团队已处理所有发现的问题」；但这次引发争议的内存问题并不属于审计条目，当时也没有对外说明。
问题出在 OOM 触发后的内部状态残留
基金会解释，PHP 设有 memory_limit，也就是单一请求可使用的内存上限。如果请求在错误的时点撞上这个上限，进入 OOM，也就是内存耗尽状态，PHP 可能留下只初始化到一半的内部数据，之后又把这些数据当成有效内容继续使用，最终造成内存损坏。
修补困难的地方，不在单一组件，而是在内存管理和错误处理这类几乎每个请求都会经过的底层位置。基金会称，几种修法要么会破坏向下兼容，要么会引入新的拒绝服务风险，要么会迫使大量第三方扩展同步修改，因此团队迟迟无法拍板，补丁工作多次停摆后又重来。
根据 GitHub 安全公告，最终采用的修补方式，是移除原本一遇到内存不足就直接中止请求的机制，改为在下一个安全点再停止。这等于重写 PHP 处理内存耗尽的方式。基金会也提到，真正熟悉引擎深层实现的核心开发者人数有限，而且很多人身兼多职，修补过程因此反复拖延。
2026 年夏天出现转折
基金会称，真正让这项问题升为第一优先的转折点出现在 2026 年夏天。PHP 被纳入 OpenAI 的 Patch the Planet 计划后，Calif 于 7 月 30 日开始审计。
8 月 11 日，Calif 研究员 Ryan Austin 回报了一个不需要特殊条件就能实现远程代码执行的漏洞，其根因与 2024 年发现的内存问题相同。OpenAI 也在同一天独立回报了同一根因。随后，Wiz 在 8 月 24 日、OpenAI 在 9 月 18 日继续补上攻击路径，漏洞影响范围才逐步清晰。
基金会表示，从那之后，这项修补成为安全人力的第一优先事项，多人全职投入，两个多月后才发布补丁。
Calif：11 款应用可在未登录状态下被打穿
Calif 的说明列出 11 款可在未登录状态下被攻破的应用，其中包括 WordPress、Drupal 和 Joomla。该公司还指出，最早受影响的程序路径可以追溯到 2012 年发布的 PHP 5.4.0。
Ryan Austin 写道，他没有使用特殊框架，也没有依赖普通人拿不到的模型，而是基于自己对目标漏洞历史的熟悉程度，再引导 AI 朝那个方向搜索。他写道：「LLM 默认会从最新、最显眼的漏洞往附近的旧代码找，不太会主动从冷门的 20 年前利用手法开始。」
基金会称已调整内部决策机制
对于后续改进，基金会表示，已经开始让决策可以通过多数决推进，并鼓励采用折中方案。今后如果严重漏洞的修法卡在艰难取舍上，会更早提交给领导层协助推进。
基金会还提到，5 月已成立生态系统安全团队，并有新人加入。自 7 月 1 日以来，团队已发布 15 个 CVE，另处理了 106 份无效、重复或无法重现的回报。
基金会同时呼吁企业、云服务商和政府提供资金支持。其说法是，PHP 支撑着政府服务、网店和银行，但安全工作目前仍主要依赖少数出资聘请的开发者和少量志愿者。
官方给网站管理者的建议：直接升级
基金会给网站管理者的建议很直接：升级到 8.5.12、8.4.27、8.3.36 或 8.2.35。所有处理网页请求的 PHP 环境都在影响范围内，包括 PHP-FPM、mod_php、FrankenPHP 和 LiteSpeed。
对于 PHP 8.1 以下版本，官方已不再提供更新。安全团队另外为 7.4、8.0 和 8.1 提供了最小化源码补丁，供自行编译的用户使用。
临时缓解措施包括将 memory_limit 设为 -1，或调低 post_max_size，但基金会强调这些办法都不完整，完整解法只有升级。