波及全球70%网站！PHP2Shell 漏洞引爆安全圈：AI 正在改写攻防安全规则|php|shell|wordpress|代码|内存|安全圈|服务器

2个高危 CVE・4 种利用路径・PHP 核心引擎级漏洞・全版本覆盖**

10 月 21 日，全球网络安全圈迎来一枚重磅炸弹：知名安全机构Wiz Research公开了一组代号为PHP2Shell的 PHP 核心引擎严重内存漏洞。

缺陷代码在 PHP 中已经存在超过十年，覆盖 PHP 5.4 之后发布的所有版本，波及全球 70% 的网站。攻击者无需任何认证权限，远程即可实现服务器代码执行、读取进程内存中的密码、API 密钥、身份令牌等敏感数据。

更讽刺的是：这组过去因利用复杂度极高、几乎只存在于理论中的漏洞，正是在前沿 AI 大模型的辅助下被成功挖掘并被武器化于黑客工具中。业内普遍认为，PHP2Shell会成为AI时代第一个 Heartbleed/Log4Shell 级别的基础设施安全事件，它也正在重新定义 “可被利用漏洞” 的边界。

一、核心信息速览

漏洞编号：CVE-2026-109618、CVE-2026-109619，最高严重等级CVSS 9.2
影响范围：PHP 5.4 及之后所有版本；覆盖 WordPress、Drupal、Joomla、MediaWiki 等绝大多数 PHP 应用，甚至仅含 “Hello World” 的最简 PHP 页面同样存在风险
攻击危害：无需认证远程代码执行（RCE）、无需认证读取服务器进程内存数据
修复状态：PHP 官方已于 10 月 21 日同步发布安全补丁，强烈建议所有环境立即升级修复
行业指示：AI 大幅降低了复杂内存漏洞的挖掘与利用门槛，原本需要顶级安全团队数月完成的工作，单人借助 AI 一周即可完成

PHP 是互联网的基石语言之一，全球超过 70% 的网站运行在 PHP 之上。和普通应用层漏洞不同，PHP2Shell 的问题出在PHP 核心引擎本身，与上层业务代码无关 —— 只要服务器运行了受影响的 PHP 版本，无论应用代码写得多么安全，都无法幸免。

这类基础组件级漏洞的破坏力，我们在 2014 年 Heartbleed（OpenSSL 漏洞）、2021 年 Log4Shell（Java 日志组件漏洞）中都已见证：一次漏洞爆发，就能震动整个互联网生态。而 PHP2Shell，正是 AI 时代第一个同量级的标志性安全事件。

二、两大 CVE，四类攻击路径

本次披露的所有漏洞都属于内存安全问题，根源是 PHP 在处理内存不足等致命错误时，没有正确清理内部状态，导致后续请求可以复用 “已过期” 的内存数据，最终造成内存泄露或任意代码执行。

研究人员共发现 4 种可稳定利用的漏洞变体，归类在 2 个 CVE 编号下：

注：以上仅为已验证的 4 种利用方式，PHP 代码库中大概率还存在更多同类变体。本次官方补丁从底层修复了错误处理逻辑，可一次性解决所有相关变体。

Wiz 团队将这些漏洞整合为单一利用脚本 php2shell，并在 WordPress、Drupal、Joomla 的最新官方容器镜像上，完整复现了无需认证的远程代码执行。

三、真正的拐点：AI 把 “不可能” 变成了可能

PHP2Shell 最特殊的地方，不在于漏洞本身有多精巧，而在于它彻底改写了漏洞利用的难度曲线。

这些有问题的代码已经存在了十几年，之所以迟迟没有被武器化，核心原因就是利用难度太高：

需要串联多个独立的缺陷点，形成完整利用链
需要精准适配不同 PHP 版本、不同配置、不同应用的内存布局
每更换一个目标环境，就要大量重新分析、测试、调试
在 AI 出现之前，这种级别的漏洞利用，需要世界顶级安全团队投入数月时间，几乎无法规模化

而前沿大模型彻底打破了这个局面：

漏洞发现：AI 可以快速扫描庞大的代码库，识别人工容易忽略的深层逻辑缺陷
Exploit 开发：AI 能自动分析攻击失败的原因，迭代调整利用代码，快速适配不同的内存环境
成本骤降：原本需要顶级团队数月的工作量，单个研究员借助 AI 在一周内就能完成

Wiz 团队在研究中使用了 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6 Sol，其中 Gemini 4 Argon 在漏洞发现、利用开发、攻击检测、补丁验证等环节都起到了关键作用。

这件事带来的影响是深远的：过去很多 “理论上存在、但实际无法利用” 的漏洞，现在都可能变成真实威胁。依赖 “复杂度” 形成的安全屏障，正在被 AI 快速瓦解。

四、技术深度解析

1. Upload-progress unserializer use-after-free（上传进度反序列化释放后重用）

PHP 的 Session 模块会在上传进度处理阶段，提前解码会话数据。反序列化器会将请求相关的状态数据存储在 BG(unserialize) 全局结构中。

如果此时触发内存不足的致命错误，请求的堆内存会被销毁，但反序列化器的全局状态不会被重置。当同一个 PHP 工作进程处理下一个请求时，会将攻击者可控的、已被释放的内存区域，当作有效的反序列化数据来读取，从而形成强大的内存破坏原语。

研究人员将其与内存泄露漏洞结合，消除了地址不确定性，最终在 WordPress、Drupal、Joomla 上实现了无需认证的远程代码执行。

2. Remote process-memory disclosure（远程进程内存泄露）

PHP 在请求启动的极早期（正常模块初始化完成前），就会解析 RFC1867 多部分表单请求。此时会话上传进度处理会初始化 Session 状态，并生成会话 ID 存储在 PS(id) 中。

如果此时发生内存不足错误，请求会异常终止，但 PS(id) 指针不会被清空，仍然指向已释放的内存。下一个请求复用该进程时，PHP 会把这个过期指针当作有效的 zend_string，将内存中的原始数据 URL 编码后，写入 PHPSESSID 响应 Cookie 返回给攻击者。

最关键的是：哪怕应用代码从未调用过session_start()，这个漏洞依然可以触发，完全不受上层应用影响。

3. Fatal-error backtrace use-after-free（致命错误回溯释放后重用）

受影响的 PHP 版本会将最近一次致命错误的调用栈，保存在全局变量 EG(last_fatal_error_backtrace) 中。

当内存不足导致请求异常终止时，堆内存被销毁，但这个全局的回溯指针没有被清除。如果下一个请求在执行早期输出了诊断信息，就会访问这个已经失效的指针，触发 use-after-free 漏洞，形成可控的内存破坏。研究人员利用该路径实现了 Drupal 的无需认证远程代码执行。

4. OPcache type confusion（OPcache 类型混淆）

OPcache 是 PHP 的字节码缓存组件，会将编译后的 PHP 结构存储在共享内存中，通过索引与每个进程的运行时指针映射配合工作。

在 zend_accel_script_persist() 执行过程中，进程本地的索引指针 CG(map_ptr_last) 会先推进，共享内存的索引标记会后更新。如果两步中间发生内存分配失败，进程本地的索引推进会被保留，但共享内存仍认为对应槽位是空的。

当另一个进程复用这些 “空闲” 槽位存储其他对象时，就会出现类型不匹配，造成跨进程的共享内存破坏。研究人员以此实现了 WordPress 的无需认证远程代码执行。

五、修复与缓解建议

1. 根本解决方案：立即升级 PHP 补丁

PHP 官方已在 10 月 21 日发布了修复版本，覆盖所有受支持的 PHP 分支。升级补丁是唯一能彻底修复该漏洞的方案，建议所有 PHP 环境尽快完成更新。

2. 临时缓解措施（无法立即升级时）

启用 WAF 防护规则：Cloudflare、AWS、Akamai 等主流云厂商与 CDN 服务商已同步推出 PHP2Shell 防护规则，可先启用规则拦截攻击流量
加强异常监控：重点关注异常的多部分表单请求、伴随大量 HTTP 500 错误 / 内存超限日志、大小或格式异常的Cookie、无理由的 PHP-FPM 进程重启
PHPSESSID
配置加固：可通过限制 PHP 单进程内存、禁用 OPcache 等方式提高攻击难度，但无法完全杜绝风险