本文回应一个问题：PHP 引擎两个评分 9.2 的高危漏洞到底坏在哪里，以及维护 PHP 站点的工程师现在该按什么顺序处置。
漏洞机理：两类内存缺陷
两个洞合成 PHP2Shell 这一组，CVSS 评分双双到 9.2，满分十分。在受影响的部署中，攻击者无需登录即可触发远程代码执行，即 RCE。按第三方的口径，能识别后台语言的站点里，绝大多数在用 PHP，其中大量运行 WordPress 之类的内容管理系统，所以这次受检范围极广。
头一个缺陷出在计数与申请内存的先后顺序上。 引擎给每次请求划一块内存额度，用光就中断清理。内部存放数据的哈希表在新增记录时，先把记录数加一，再申请内存填内容。要是在申请新内存的一瞬撞上额度见底，流程跳去善后，清点却按虚高的数目对账。攻击者利用请求进入引擎后被拆成大量记录、每条都要额外占内存的放大效应，把耗尽额度的时机精确安排在这一步。有公开的攻击路径里，不到 8MiB 的请求数据，处理时足以耗尽默认 128MiB 的内存额度。
请求进入 → 拆分为大量记录 → 每条记录额外占用内存
哈希表新增记录：计数加一 → 申请内存 → 填充内容
若申请内存时额度耗尽：跳转清理 → 清理程序按计数
把半成品记录当有效数据使用 → 后续可导向代码执行
第二个缺陷是释放后使用，也就是 UAF。 一次请求异常结束，内存已释放，处理程序还揣着旧地址；再来请求时循着它去取，取到的兴许已是别人名下的内存。这类缺陷在长期运行的进程里危害更大，内存布局可以被反复试探。和头一类缺陷放在一起看，共同点是都藏在异常路径上：正常请求永远走不到那几行代码，测试用例很少覆盖中断与异常结束的组合，问题就这样留了下来。对写代码的人来说，这也是提醒：计数与资源申请的先后顺序、异常结束后的指针状态，属于值得在任何语言里都多看一眼的位置。
另一条值得记下的信息：在部分 Apache 与 mod_php 的部署组合中，攻击可以在网站自己的程序启动之前发生。这意味着即便业务代码本身干净，引擎层的问题照样能被引爆。
AI 在这次审计里做了什么
切入点选在二十多年前的一桩旧案，让模型沿着当年的思路去翻新代码。旧漏洞提供的不只是线索，更是一份经验证的错误模式：模型拿它当模板，去存量代码里匹配相似的结构。首条路径到手后没有停下，团队把这类错误归纳成一份指引文档，照着指引接着排查，文件上传那段代码里随即冒出第二处。这条工作流的关键在指引文件本身，一次人工确认的发现被固化成了可复用的检查步骤，后续排查不再依赖运气。另一家安全公司独立复核发现了同样的缺陷；版本一换、环境一变，攻击路径可能失效，验证过程需要反复分析崩溃现场、调整输入构造。复核方对外的口径是：工作量的大头出在模型这边。。对工程团队的启发很直接：把已确认的错误模式固化成检查项，让模型按清单扫存量代码，这套流程现在具备可行性，而且可以套用到自家代码库的内部审计上。
泄密链节点复盘
披露环节按反过来看更清楚。含修复的构建镜像先提前公开，新旧两版一对读，问题位置随即显形；再往前，攻击演示视频误发流出，删除时副本已经传开；更早一步，漏洞编号先在网上流传，还混着错误的时间与评分。官方为此把正式发布提前了 24 小时，云防护侧已经看见早期攻击，对方在变着法子试规则。镜像先出意味着攻击者拿到的是可运行的修复版本，这比编号泄露危险得多。多方参与的发布流程，保密链条每多一个持有方，风险面就大一分，这件事对任何需要协同披露的团队都是参考。
处置清单
按顺序执行，装补丁相关的动作放排头。
- 升级到已包含修复的版本。本次修复版本覆盖多个在维护的分支，旧分支另有精简版的源码级修补，长期支持方据此打包。升级前先在预发环境验证扩展兼容性，尤其是依赖引擎内部行为的扩展。
- 用官方检查脚本核对当前版本。脚本只查版本，不能替站点完成升级；查不到版本的实例要单独登记，逐台排查运行方式。
- 防护兜底。WAF 规则可以争取时间，不能顶替补丁，部署后仍须完成升级并复测。规则上线后留意拦截日志，异常请求模式本身就是暴露面的信号。
版本核查可以这样跑：
php -v
逐站点确认，重点核对是否已包含修复的版本号
多实例环境逐台执行，记录到资产清单
反代或网关侧的临时规则示例，域名一律用占位符：
your-domain.test 站点临时限流与异常请求拦截示例
server {
server_name your-domain.test;
对超长请求体与异常请求做拦截，降低触发内存耗尽的概率
client_max_body_size 1m;
规则仅作过渡，升级完成后移除
}
踩坑：这些做法没有用
踩坑一，把官方检查脚本的输出当成安全结论。脚本只查版本，查不到版本时也不能据此认定安全，长期支持场景下版本号与补丁状态可能对不上，容器化部署里镜像层叠还会让运行版本与标签不一致。踩坑二，只上 WAF 规则就停手。云防护厂商已经观察到攻击者在改请求试绕过规则，临时防护的规则集会被逐步试探穿透，不升级等于把风险留在原地。踩坑三，只升业务服务器、漏掉镜像与演示环境。构建镜像提前公开之后，任何还跑着旧版本的环境都是现成靶子，包括内网的 CI、预发与测试环境，这些机器往往权限宽、监控弱，反而更好打。踩坑四，升级后不做回归验证。引擎层面的改动可能影响扩展行为，升级完至少要跑一轮核心业务的功能验证。
补丁没装上之前，临时防护争取到的每一天都有代价。
升级慢半拍，暴露面就多一天。
两道内存上限是这次修复的关键改动：软限制触发时等程序走到安全位置再处理，硬限制触发时让进程直接退出，两道上限分别负责优雅与兜底。这个设计对自家系统也有参考价值：资源耗尽场景里，先给程序一个走到安全点的机会，实在兜不住再硬退出，比一刀切的超时更稳。
总结
这次事件给出三层结论。机理层面，计数顺序与旧地址两类缺陷都藏在边角条件下，靠常规功能测试很难覆盖，审计时要把异常路径单独列出来扫；流程层面，AI 参与审计后，发现节奏明显加快，指引文件的复用让一次发现变成了可持续的排查能力，官方预告未来几个月此类发现会显著增加；处置层面，升级是终点，检查脚本与防护规则都只是辅助，镜像、演示、预发这些容易被遗忘的环境要一并纳入盘点。