PHP2Shell漏洞解析：全球七成网站面临的远程代码执行危机

2026年10月21日，PHP官方紧急发布安全更新，修复了两个位于PHP解释器核心的严重安全漏洞——CVE-2026-109618和CVE-2026-109619，业内统称为PHP2Shell。两个漏洞的CVSS v4.0评分均高达9.2分，属于最高等级的无需认证远程代码执行漏洞。

这不是某个PHP应用的漏洞，而是PHP语言解释器本身的内存管理缺陷。这意味着——哪怕你的网站代码写得再严谨，只要底层PHP版本在受影响范围内，攻击者就可以通过发送特制的HTTP请求，直接在你的服务器上执行任意命令。

一、事件时间线

• 2026年8月：安全研究团队首次发现异常线索
• 2026年10月20日：漏洞细节意外提前泄露，安全社区开始预警
• 2026年10月21日：PHP官方提前发布紧急安全补丁（8.5.12、8.4.27、8.3.36、8.2.35）
• 2026年10月22日：多国政府网站、企业服务临时下线进行安全升级，全球范围内开始出现攻击尝试
• 2026年10月23日：国内多家高校、机构发布安全通告，未名BBS等服务暂停维护

二、漏洞技术深度解析

两个漏洞均属于内存安全问题，但触发路径和原理各不相同。

CVE-2026-109618：内存耗尽时的初始化中断

漏洞本质：哈希表计数已递增，但内存分配失败导致键值未初始化。

PHP在处理表单提交时，会将POST数据解析到$_POST数组中，内部使用哈希表存储键值对。正常流程下，PHP会先递增哈希表的条目计数器，再为键名分配内存并初始化数据。

问题出在内存耗尽（OOM）的场景：当分配键名内存时触发了memory_limit限制，PHP会通过longjmp()立即中止当前操作。此时哈希表的计数器已经包含了新条目，但条目的键和值从未被初始化，处于无效状态。

在后续的请求清理阶段，PHP会遍历哈希表进行清理，却将这些无效的未初始化数据当作有效指针来处理，最终导致内存破坏。

触发方式：攻击者构造包含大量头部、嵌套字段名或空文件控件的multipart POST请求，在看似不超过post_max_size限制的情况下耗尽memory_limit，触发OOM异常。

CVE-2026-109619：跨请求的陈旧全局状态

漏洞本质：请求内存释放后，全局状态指针未重置，导致释放后使用（Use-After-Free）。

PHP工作进程（Worker）会维护一些全局状态，包括错误信息、会话、对象和扩展状态等。当请求发生致命错误时，PHP同样使用longjmp()跳转到错误处理流程，但部分全局状态指针没有被正确重置。

请求结束后，这些状态指向的内存被释放，但指针本身仍然保留在全局变量中。当同一个工作进程处理下一个请求时，某些代码路径会在正常初始化之前访问这些陈旧的指针，从而触发释放后使用漏洞。

触发方式：攻击者在同一个Worker进程上连续发送两个请求——第一个请求制造致命错误并留下陈旧状态，第二个请求精心构造堆布局，将恶意数据填入已释放的内存区域，最终实现远程代码执行。

三、影响范围

受影响的PHP版本

注意：PHP 8.1及更早版本已停止官方维护，无法获得官方安全补丁。部分Linux发行版可能会提供移植修复，但需要联系各自的厂商确认。

受影响的部署方式

PHP官方确认，所有处理Web请求的PHP部署形态均受影响，包括：

• PHP-FPM
• Apache mod_php（风险最高）
• php-cgi
• FrankenPHP
• LiteSpeed

其中Apache mod_php架构风险最高——攻击者可以在应用代码执行之前就触发漏洞，完全绕过业务层的所有安全防护。

受影响的应用生态

由于漏洞位于PHP核心层，几乎所有基于PHP的应用都受到波及，包括但不限于：

• CMS系统：WordPress、Drupal、Joomla、Discuz、MediaWiki
• 电商平台：Magento、OpenCart、WHMCS
• 开发框架：Laravel、Symfony、ThinkPHP
• 管理工具：phpMyAdmin、Nextcloud、Roundcube

W3Techs统计数据显示，全球约70%的网站使用PHP作为服务器端语言。这意味着这两个漏洞潜在影响了互联网上超过半数的网站。

四、实际攻击难度与风险

虽然两个漏洞理论上都能实现远程代码执行，但实际利用存在一定门槛：

1. 攻击复杂度较高：需要精确控制堆内存布局，且第二个请求必须命中同一个Worker进程
2. 环境依赖性强：不同的PHP部署方式、配置参数、操作系统都会影响利用成功率
3. mod_php最易利用：Apache mod_php模式下攻击成功率最高，PHP-FPM相对困难一些

但需要警惕的是，随着安全社区的深入研究，POC（概念验证）代码已经公开，攻击手法正在快速迭代。截至10月23日，全球范围内已经观测到大量扫描和攻击尝试。

除了远程代码执行，攻击者还可以利用这些漏洞进行：

• 内存泄露：读取PHP进程内存中的密码、令牌、API密钥等敏感信息
• 拒绝服务：使PHP进程崩溃，导致网站不可用

五、修复与缓解方案

首要方案：立即升级PHP版本

PHP官方明确表示：升级到修复版本是唯一安全的选择，没有完整的临时缓解方案。

请尽快升级到以下版本：

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

临时缓解措施

如果无法立即升级，可以尝试以下措施降低风险（不能完全防御）：

1. 调低内存相关配置：减小memory_limit、post_max_size、upload_max_filesize的值，增加触发OOM的难度
2. 禁用会话上传进度：将session.upload_progress.enabled设置为0
3. 使用WAF防护：部署支持PHP2Shell漏洞防护规则的Web应用防火墙
4. 更换部署模式：如果可能，从Apache mod_php切换到PHP-FPM模式
5. 重启PHP服务：定期重启PHP-FPM或Apache，减少陈旧状态累积的概率

Docker环境注意事项

容器化部署的应用需要独立更新PHP版本，重新构建镜像。不要依赖基础镜像自动更新，务必显式指定修复后的PHP版本号。

六、事件背后的思考：AI与漏洞发现

值得关注的是，这两个在PHP代码中潜伏了十余年的深层漏洞，最终是由AI辅助发现的。据披露，安全公司Calif借助OpenAI的GPT-5.6 Sol模型识别了关键漏洞模式，Wiz团队也在研究过程中使用AI工具进行代码分析和漏洞验证。

这标志着网络安全正在进入AI加速时代：

• 防御方：AI大幅降低了发现复杂内存漏洞的门槛，过去需要资深专家数月分析的问题，现在可能几周就能突破
• 攻击方：AI同样可以帮助攻击者快速优化漏洞利用技术，缩短补丁发布到攻击扩散的时间窗口

正如微软CEO萨蒂亚·纳德拉所说：”对于所有信息技术和网络安全从业者来说，这是漫长的一天一夜。这一事件充分反映，在网络系统日益复杂的背景下，打造可安全维护的软件非常重要。”

七、总结与建议

PHP2Shell是近年来PHP生态最严重的安全事件之一。漏洞位于语言核心层、无需认证、影响范围广，且已经出现公开的利用代码。

给运维和开发者的建议：

1. 立即自查版本：执行php -v确认当前版本，不在修复列表内的尽快升级
2. 优先升级高危环境：Apache mod_php部署的服务器应第一时间处理
3. 关注下游应用：WordPress等CMS的托管用户，需关注服务商的安全更新
4. 建立应急响应：监控异常请求和服务器进程状态，准备回滚预案
5. 长期规划：评估PHP版本生命周期，制定定期升级策略，避免停留在停止维护的版本

网络安全没有一劳永逸。这次事件再次提醒我们：底层基础设施的安全，才是整个应用安全的基石。

PS：
大模型给安全行业带来的冲击十分巨大，传统安全防护手段被击穿的可能性越来越高。