php2shell远程执行漏洞修复（CVE-2026-109618 和 CVE-2026-109619）

一夜之间，PHP世界的天塌了。

2026 年 10 月 21 日，PHP 官方正式发布紧急安全更新，修复两项严重安全漏洞：CVE-2026-109618 和 CVE-2026-109619。

两项漏洞的 CVSS v4.0 评分均为 9.2 分（严重），攻击者可能在未经身份验证的情况下，利用漏洞实现远程代码执行（RCE）。

这两个漏洞其实最早在8月份就已经被发现了，更夸张的是，这两个坑已经被埋了十几年。先说明最重要的修复漏洞相关的，后面再吐槽……

漏洞说明

1. CVE-2026-109618：OOM内存处理漏洞（RCE）

GHSA: GHSA-w8hw-w9fx-j79w

• 原理：PHP 在触发 memory_limit OOM 时，使用 longjmp() 直接中断请求。此时请求内部数据还没完全初始化，请求清理逻辑会把无效内存当成合法对象处理，造成内存破坏。
• 攻击向量：特制 multipart/form-data POST（大量嵌套表单字段、空文件上传控件），在不突破 post_max_size 的前提下快速耗尽内存触发OOM。
• 重点：mod_php 环境最危险，无需业务代码运行，请求阶段就触发。

2. CVE-2026-109619：陈旧全局状态 / Use-After-Free（RCE）

GHSA: GHSA-6wmf-4rv5-p3rp

• 原理：请求致命错误释放内存后，仍残留旧请求状态引用。同一个FPM/mod_php工作进程处理下一个请求时，在初始化重置之前访问已经释放的旧状态，造成use-after-free，可实现RCE、信息泄露。
• 触发条件：跨请求复用同一个worker进程，旧请求崩溃后状态未清理干净。PHP-FPM环境可利用。
• 临时缓解：关闭 session.upload_progress.enabled = 0，并配置FPM进程定期重启（pm.max_requests），减少跨请求状态残留风险。

受影响版本 & 修复版本

PHP8.1及以下的版本不支持安全更新，这个需要尽快升级到新版本。

所有对外提供Web请求的SAPI都受影响：mod_php、PHP-FPM、php-cgi、FrankenPHP、LiteSpeed PHP。

应急处置方案（优先级：升级 > 临时缓解）

首选：升级PHP到上面安全版本

• 升级后必须重启php-fpm / apache，旧worker进程不会自动加载新版二进制。
• 升级后检查 php -v 和 phpinfo() 确认版本。

临时缓解（业务无法立刻升级时，不能完全根治，仅降风险）

1. php.ini：session.upload_progress.enabled = Off
2. PHP-FPM：设置 pm.max_requests（例如 200~500），强制worker进程定期销毁重建，切断跨请求残留状态
3. WAF：拦截异常 multipart POST 请求（超大表单字段、大量嵌套文件上传控件）
4. 临时收紧 memory_limit，但容易误伤正常业务，不推荐优先使用
5. 流量侧：限制POST上传请求频率、单请求表单字段数量

官方明确：临时配置不能完全消除漏洞，升级是唯一彻底修复手段。

自查命令

# 查看php版本
php -v

# 查看FPM pool配置
grep -E "session.upload_progress.enabled|pm.max_requests" /etc/php/*/fpm/php.ini /etc/php/*/fpm/pool.d/*.conf

常见误区

1. “我的网站没有文件上传接口就不受影响”：漏洞在PHP内核multipart解析，只要接受POST multipart请求就可触发，和业务代码是否有上传功能无关。
2. “使用Nginx+PHP-FPM就安全”：FPM可被CVE-2026-109619利用，风险低于mod_php，但依然高危。
3. “WAF可以完全挡住”：WAF只能拦截已知payload，内存类漏洞变种容易绕过，不可替代补丁。

接下来吐槽吐槽。

php2shell是PHP内核层面的两个内存安全漏洞，不是WordPress、Drupal这类应用漏洞；无认证即可RCE，CVSS 9.2。

发现主体：Calif Research（借助OpenAI GPT-5.6 Sol）；Wiz团队独立复现并提交报告，OpenAI的Patch the Planet安全计划作为协作背景。

漏洞历程

一、历史伏笔（为什么这个坑埋了十几年）

1. 2004年：安全研究者Stefan Esser最早发现PHP memory_limit OOM中断带来的内存破坏利用思路，但当时没有公开完整EXP，属于历史上同家族漏洞的源头。
2. 2020年：有人提交PHP bug #78876，描述multipart解析触发OOM时临时文件清理异常；当时只当成小bug，没有证明可RCE，未修复。
3. 2024年：OSTIF+Quarkslab审计PHP，再次挖到这个相关OOM问题；但依然无法稳定构造RCE利用链，所以PHP项目没有打补丁，问题遗留。

核心本质：PHP的错误处理机制依赖longjmp做非局部跳转，遇到OOM/致命错误时会立刻中断执行，跳过很多正常的初始化、对象销毁、状态重置逻辑。多年来大家知道这个代码模式有风险，但一直没找到可靠完整的RCE链路。

二、漏洞发现过程（2026年）

Calif团队参与OpenAI「Patch the Planet」计划，目标审计高影响力开源软件，选定PHP。研究者带着2004年、2020、2024年遗留的OOM历史漏洞线索，使用大模型辅助源码静态分析，寻找可被利用的中断点。

1. 2026-08-01：Calif找到第一条可稳定RCE的OOM触发路径，继续深挖，最终定位到两个独立漏洞：CVE-2026-109618（OOM中断内存破坏）、CVE-2026-109619（跨请求use-after-free）。
2. 2026-08-11：Calif正式向PHP安全团队提交第一个漏洞，启动协调披露流程（Coordinated Disclosure）。
3. 2026-08-14：提交PoC，证明无认证RCE可行。
4. 2026-08-15：PHP官方确认PoC有效。
5. 2026-08-21：提交第二个漏洞（use-after-free）。
   • 同期Wiz团队独立发现同类漏洞，并且验证了在WordPress、Drupal上直接RCE。
6. 接下来2个月：PHP基金会开发补丁、多轮测试；各方约定原定10月22日晚统一对外发布公告+补丁。

三、泄密事件：披露提前（关键转折点）

协调披露的前提：在正式发布前，漏洞细节、EXP严格保密，留给全球运维打补丁的窗口期。

• 10月20日夜间：漏洞编号、漏洞信息意外泄露到外网；随后漏洞演示视频流出，EXP副本快速扩散。
• 漏洞细节泄露之后，攻击者已经可以开始分析、构造利用载荷，还没拿到官方补丁。
• PHP基金会被迫紧急提前24小时发布安全版本，也就是10月21日UTC 14:00，提前上线修复包，同步公开漏洞公告。
• Cloudflare等厂商在正式披露前紧急上线WAF临时防护规则；同时互联网上开始出现针对php2shell的探测和攻击行为。

因为漏洞的提前披露，以及使用漏洞攻击的视频在互联网上流出，欧洲大量的政府网站暂停服务，紧急修复这个漏洞，就连高市早苗这个不务正业的首相都发推提醒，可见影响范围之大。

我这一大早也是开始更新了自己网站的php版本，忙活了一上午，算是略微心安了一点，因为不知道还有多少的漏洞没有被披露，互联网太危险了……

你的网站PHP版本更新了没？