PHP2Shell高危漏洞复盘：AI如何让复杂内存漏洞变成远程代码执行？

安全牛 2026-11-11 12:07 北京

从代码安全到运行环境,从漏洞发现到修复验证,从单一产品防护到整个技术生态的联合治理——安全能力必须贯穿软件完整生命周期。

2026年10月21日,PHP项目组紧急发布安全更新,修复两个超严重远程代码执行漏洞(CVE-2026-109618和CVE-2026-109619),CVSS评分都到了9.2分,统称PHP2Shell。

为什么这事这么受关注?不光是因为PHP用得广(全球约70%的网站),更关键的是:这次从发现漏洞到验证利用,AI起了决定性作用。那些过去因为太复杂、利用难度高而一直潜伏的底层代码问题,现在可能被AI迅速转化成现实威胁。

这次问题不是某个WordPress插件或者业务代码的bug,而是PHP引擎核心的内存处理机制。简单说,就是PHP处理请求时遇到严重错误(比如内存耗尽),部分内部数据结构没清理干净。

CVE-2026-109618:内存耗尽时,某些内部状态损坏。攻击者可以利用这个在不登录的情况下远程执行代码。

CVE-2026-109619:致命错误后留下的无效状态。后续请求使用这些状态时,会产生"释放后使用"(Use-After-Free)这种内存安全问题。

关键是,这些漏洞利用起来很复杂,涉及多个条件组合:PHP版本、运行模式、内存布局、请求处理逻辑等。这也是为什么这些问题能存在这么久却没被广泛利用——以前太难了。

Wiz Research的研究团队说得很直白:没有AI,他们很难完成这次复杂漏洞研究。

他们用了Wiz Atlas、Gemini 4 Argon、GPT-5.6 Sol等工具,在一个周末就测试了几十种研究思路。整个过程是这样的:

• 代码分析:AI帮忙分析PHP核心代码里异常处理、内存分配的可疑路径

• 假设验证:在测试环境验证这些问题是否真的会导致内存损坏

• 持续迭代:失败了就调整方法,AI协助分析原因,再试

• 人工复核:最后由专业研究人员确认风险,研究修复方案

研究团队在8月19日发现首个漏洞,8月20-21日就在Drupal和WordPress环境里确认了未授权远程代码执行。还验证了即使不能执行代码,也可能读取PHP进程内存里的密码、令牌、API密钥等敏感数据。

重点来了:AI降低了复杂漏洞研究的门槛。过去那些"太难利用所以风险可控"的假设,现在不太靠得住了。

这次不是某一家单打独斗。涉及PHP安全团队、PHP Foundation、Wiz Research、Calif、OpenAI,还有一堆云服务商和安全厂商。

时间线梳理:

• 2024年:PHP项目在安全审计中注意到内存耗尽处理的潜在问题,但因为缺乏明确利用路径、修复可能影响兼容性,就没彻底解决

• 2026年8月:Calif、OpenAI、Wiz等机构相继提交发现和攻击路径

• 8月24日:Wiz正式向PHP安全团队报告

• 10月21日:PHP正式发布安全更新,涵盖8.2.35、8.3.36、8.4.27、8.5.12等版本

整个链路是:研究机构发现并验证→开源维护者分析根因开发补丁→生态伙伴准备检测缓解→软件分发渠道组织更新→企业用户执行升级验证。每个环节都不能少。

原计划10月22日公开,结果10月20日CVE编号就提前出现在论坛和社交媒体上,还有不准确的信息。PHP项目组只好提前到10月21日发布。期间还发生了验证材料意外公开、软件分发方提前发布镜像等情况。

教训:重大漏洞披露不能只考虑时间,必须确保用户能及时获得可安装、可验证的修复方案。参与方越多,信息管理难度越大。企业要提前准备披露计划变化、技术细节提前扩散等特殊场景。

多层防护机制:

• 临时缓解:Cloudflare等云服务商在10月21日前就部署了WAF防护规则。但要注意,WAF不能完全防护所有利用路径,只是临时措施。

• 版本升级:更新PHP才是根本。企业需要:

• 准确识别所有用PHP的资产(不只是网站,还要确认底层PHP版本、运行模式、部署位置)

• 区分实际受影响资产(不同版本、配置、运行方式,可利用性不同)

• 确保补丁真正进入运行环境(长期运行的进程需要重启或重新加载)

• 验证线上实际运行版本

• 监测异常:关注异常的多部分表单请求、内存限制错误、频繁的HTTP 500响应、异常会话Cookie、PHP工作进程频繁重启等信号。

根据Wiz在10月27日的监测,从10月21日漏洞公开以来,互联网暴露的相关易受攻击主机每日去重数量下降了约67%,至少存在一台暴露实例的组织数量下降约47.9%。

但要注意:

• 这只是Wiz监测范围内的数据,不代表全球情况

• 暴露数量下降不等于全部装了补丁(可能是下线、限制访问等)

• 仍然监测到针对PHP2Shell的攻击尝试

真正的风险治理要回答三个问题:

• 安全更新覆盖率:是否识别了全部受影响实例?

• 修复措施的实际有效性:补丁是否真的进了生产环境?

• 剩余风险的管理:暂时无法更新的系统有什么补偿措施?

五个最佳实践:

1. 建立软件资产清单不只是服务器名称和IP,要覆盖运行时环境、操作系统、应用框架、开源组件及依赖关系。初创企业从早期就要建立,别等规模大了再补。

2. 安全修复纳入自动化流程把组件安全检查、基础镜像更新、依赖升级、兼容性测试和部署验证标准化。但自动化不等于省略测试和审批,核心环境更新还是要评估兼容性、业务连续性。

3. 用AI提升验证能力,不是替代判断可以用AI辅助代码审查、漏洞报告分类、组件风险分析、检测规则验证。但AI生成的结果必须经过验证——PHP Foundation指出,AI辅助研究让漏洞报告显著增加,但大量是无效、重复或无法复现的。

4. 提前设计协同处置机制明确重大漏洞事件的响应负责人、跨部门沟通渠道、紧急变更授权机制。用云服务、CDN、WAF的,要明确服务商与企业的安全责任边界。

5. 长期安全治理与应急响应相结合定期评估核心软件组件的生命周期状态、维护活跃程度、升级可行性。停止维护的组件建立替换计划;承担重要业务的开源基础设施,关注维护团队的安全响应能力。

PHP2Shell最重要的启示:过去依赖漏洞利用难度维持的安全缓冲正在缩小。

AI时代的安全竞争,不再只是比拼谁发现更多漏洞,而是考验:

• 谁能更快确认风险

• 谁能更准确识别受影响资产

• 谁能以更低成本完成可靠修复

真正有竞争力的企业,不只是拥有先进安全工具,更是能将技术研究、资产管理、工程实践和组织响应整合为持续安全治理能力。

从代码安全到运行环境,从漏洞发现到修复验证,从单一产品防护到整个技术生态的联合治理——安全能力必须贯穿软件完整生命周期。

这就是PHP2Shell给网络安全行业上的一课。

跳转微信打开