PHP2Shell 发现者复盘了，这个 9.2 分的严重安全漏洞，在 PHP 里藏了 22 年！
内容提要
安全机构复盘PHP“php2shell”漏洞：该漏洞可追溯至PHP 5.4.0，潜伏约22年，成因是请求处理被内存溢出或致命错误打断后，残留状态被下一请求误用，可导致远程代码执行。WordPress、Drupal等应用受影响。PHP-FPM因崩溃即重启进程相对安全，mod_php风险更高。官方已于2026年10月21日发布补丁，建议立即升级，临时措施仅为权宜之计。
延伸解读
运行模式决定风险差异
文章指出，PHP-FPM 在请求启动阶段崩溃时会直接丢弃工作进程并重新拉起，残留状态随之消失，因此对两条利用路径免疫；而 mod_php 不丢弃进程，下一个请求会继续使用同一进程，风险更高。不过，与具体应用相关的第三条路径在两者上都成立，只要应用在启动后执行 session_start()、unserialize() 等解码操作，就可能被利用。
临时缓解措施有代价
在无法立即升级时，文章给出的临时措施包括：PHP-FPM 关闭 session.upload_progress.enabled 并将 memory_limit 设为 -1；mod_php 同样将 memory_limit 设为 -1。但作者明确警告，去掉内存上限等于撤掉 PHP 的内存闸门，反而会增大内存耗尽风险。这些措施只能争取时间，不能替代补丁。
AI 挖洞仍依赖人的判断
复盘特别说明，发现过程中没有使用特殊测试框架或非公开模型。研究者强调“了解你的目标”依然关键：模型默认倾向于追踪最新、最显眼的漏洞，不会可靠地从二十年前的模糊利用原语出发。因此，保留目标漏洞历史目录并明确引导模型，才能让 AI 辅助审计真正发挥作用。
Q&A
PHP2Shell 漏洞的根本原因是什么？
PHP 处理请求时，如果内存分配超出 memory_limit 或发生致命错误，导致请求处理被强行打断，残留的半初始化状态不会被清理。下一个请求在同一进程内存中继续运行时，会误用这些残留状态，从而可能造成内存泄露和远程代码执行。
哪些 PHP 运行方式受 PHP2Shell 影响较小？
PHP-FPM 相对安全：请求启动阶段崩溃时，FPM 会丢弃并重启工作进程，残留状态随之消失。mod_php 风险更高，因为进程不会重启，下一个请求会继续使用未清理的状态。但 FPM 并非完全免疫，应用层解码操作（如 session_start、unserialize）仍可能被利用。
PHP2Shell 漏洞最早可以追溯到哪个 PHP 版本？
最早受影响的代码可追溯到 PHP 5.4.0，该漏洞在 PHP 中潜伏了约 22 年。
哪些知名应用受 PHP2Shell 漏洞影响？
确认可免登录实现远程代码执行的应用包括：WordPress 7.1.2、Drupal 11.4.3、Joomla 6.1.4、MediaWiki 1.46.2、Roundcube 1.7.4、Magento 2.4.9、phpMyAdmin 5.2.3、Nextcloud 35.0.1、Laravel 13.11、Symfony 8.1、WHMCS 等。
PHP2Shell 攻击的大致步骤是什么？
第一步，发送大量空壳上传记录，消耗 PHP 堆内存（默认 128 MiB），在请求体限制内触发内存溢出崩溃；第二步，利用请求处理被中断后留下的未清理状态；第三步，让同一工作进程的下一个请求误用这些陈旧状态，最终实现远程代码执行。
如果暂时无法升级 PHP，有哪些临时缓解措施？
对于 PHP-FPM：关闭 Session 上传进度（session.upload_progress.enabled=0），并将 memory_limit 设置为 -1。对于 mod_php：将 memory_limit 设置为 -1，但这会取消内存上限，增加内存耗尽风险。这些只是权宜之计，根本解决方案是立即安装官方补丁。
PHP2Shell 漏洞是什么时候被修复的？
PHP 官方于 2026 年 10 月 21 日正式发布了安全补丁，修复了该漏洞。建议所有用户立即升级到安全修复版本。
