PHP 基金会最近很少这么坦诚。10 月 21 日它发了一篇博客，交代两个远程代码执行漏洞是怎么被拖了两年才修好的，里面有一句话大概让很多靠 PHP 吃饭的公司心里一沉："修复的延误是结构性的失败，既源于安全团队的决策流程，也源于它资源不足。"

同一天，路透社记者围绕这个话题问了基金会董事，报道标题更直接：PHP 基金会资金不足，全职员工只有一名。

两个漏洞本身值得先说说。CVE-2026-109618 是 OOM 内存破坏：请求在恰好撞上 memory_limit 的瞬间，PHP 会留下部分初始化的内部数据，之后被当作有效数据使用，造成内存破坏。在 Apache + mod_php 上，未认证请求就能在应用代码运行前触发，默认配置下已被演示实现完整 RCE。CVE-2026-109619 是过期全局状态：某个致命错误会让内部状态指向上一个请求释放掉的内存，同一 worker 处理下一个请求时就用到了这块已释放内存，确认了 use-after-free 和 worker 崩溃。

这两个漏洞都出在 PHP 几乎每个请求都会碰的地方——内存管理和错误处理。正因如此，修起来极难：既要兼容性、不能伤性能，还要顾全庞大的第三方扩展生态。

难点还不止于此。基金会承认，问题早在 2024 年就被理论化，但没有明确的利用路径，加上"熟悉引擎深处、有足够能力的核心开发者太少"，修复在几个月里反复启动又停滞。"安全团队靠共识决策，害怕选错方案带来的后果，又担心破坏兼容性——这个决策过程让修复拖了又拖。"

转折发生在今年 8 月。基金会的 AI 安全工程师在 2024 年修复 Quarkslab 审计问题时发现了 OOM 问题的第一个迹象；8 月 11 日，安全公司 Calif 的研究员报告了同一根因的无条件 RCE，OpenAI 独立报告了同一根因，随后 Wiz、OpenAI 又陆续给出更多攻击向量。从那天起，修 OOM 成了基金会所有安全工作者的最高优先级。"没有基金会的资金，不可能让多人全职扑在这个问题上，甚至在周末和全天候地协调沟通。"

那基金会有多少人？官网 structure 页写着：基金会签约了 13 名全职/兼职工程师维护 PHP 语言本身；负责运营和募资的正式员工只有执行总监 Elizabeth Barron 和募资总监 Ben Marks 两人；董事会 12 名成员不拿报酬。博客自己的结语是："PHP 的安全工作仍然依赖一小群基金会资助的开发者，外加少量志愿者帮助。工具现在比人更快地发现 bug，报告数量只会继续增长——但决定正确修复方案、权衡兼容性取舍、审核补丁，这些需要熟悉整个 PHP 代码库的经验丰富的工程师，而今天这样的人太少了。"

一个支撑着政府服务、银行、电商、媒体网站的语言，安全维护力量薄成这样，路透社这篇报道把它摆到了台面上。漏洞修复后，基金会一边呼吁依赖 PHP 的公司按"你有多依赖它"来赞助，一边把安全团队从"共识决策"改成"多数决、鼓励妥协"——都是被这次事故逼出来的调整。但对整个 PHP 生态来说，真正的问题没变：这个语言太普及了，普及到大家默认它会一直有人维护，而实际上维护它的人少得不成比例。

参考来源

• Reuters: PHP Foundation under-funded with one full-time staff member, director says
• The PHP Foundation: Today's PHP Security Release, and How We're Strengthening PHP Security
• The PHP Foundation: Structure
• php.net: PHP 8.5.12 release archive