一个支撑着约71%网站的语言，负责维护它的基金会，全职员工只有一个人。PHP基金会执行董事伊丽莎白·巴伦（Elizabeth Barron）在接受路透社采访时把这件事说得很直白：她是团队里唯一一个全职的人，其余工作靠14名“大多为兼职”的合同人员分担。
这支团队要开发和维护PHP核心，安全修复也在其中。核心团队接受来自外部的贡献，运作方式和Linux内核开发有些相似——但Linux内核那边人手充足得多，有大量全职贡献者和公司雇佣的开发者。巴伦同时提到，在安全补丁发布之前，没有收到PHP2Shell被利用的报告。
资金不足很可能导致了没能及时处理底层漏洞的“结构性失败”。最终引发2026年漏洞利用的内存耗尽（OOM）问题，最早在2024年就被发现了。考虑到PHP的普及程度和庞大的第三方扩展数量，修复OOM问题的工作“在数月里反复停滞又重启”。Chainguard安全公司还不慎过早打破了PHP2Shell的禁令，让情况更糟。
即便如此，团队仍对现有的资金心存感激：没有基金会的资助，就不可能让多个人全职投入这个问题，最终在周末和全天候轮班中与其他相关方协调沟通。人们大概会希望这次事件能让更多靠PHP吃饭的公司松开钱袋。
但问题远不止核心语言里的漏洞——修补它只差一次版本更新。理论上，任何运行当前8.x版本的服务器都能在几分钟内完成升级，现实却大不相同：出于对漏洞被利用的恐惧，不少网站下线了数小时甚至数天。
真正的问题浮出水面：近73%的PHP安装运行着早已过了生命周期终点（EOL）的版本，获取修复因此难上加难。许多和这门语言打过交道的从业者，包括本文作者，几十年来一直在警告这笔迟早要还的账，甚至考虑到不少Linux发行版在回移修复补丁。
这些服务器里有很多还跑着PHP 7——这个版本四年前就已彻底EOL，此前有多年预警，它最初发布于2015年末，距今近十一年。如果这还不够荒唐，那么请记住：约7.7%的PHP站点仍在运行5.x版本，它2005年问世，2018年正式谢幕。可以说，所有人都曾有充足的时间做准备。
更能说明集体自满有多离谱的是：从PHP 5跳到7、再从7跳到8，确实需要改动部分网站代码，但绝大多数改动都容易找到并应用，甚至在AI出现之前，自动化代码修补工具就已经存在。几年前，作者本人就为一次PHP 5到8的代码库转换把这些工具逐一梳理过。
大部分改动是放弃对古老函数和库的支持，而这些函数和库本身早已长期警告即将弃用。核心语言特性改动不多，还新增了不少便利语法，帮助理清那些繁琐易错的代码。局面走到今天这一步令人难以置信，也说明自满、懒惰和削减成本，是比一群AI机器人四处挖漏洞更强大的力量。
热门跟贴