2026-10-24 15:14:35 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

捕获 PHP 远程代码执行漏洞 CVE-2026-109618 / CVE-2026-109619 攻击载荷

原创

小话安全
小话安全

小话安全

2026年10月22日 09:02
山东

去阅读

2026 年 10 月 21 日，PHP 安全团队发布了紧急安全更新，修复两个 CVSS 评分 9.2 的远程代码执行漏洞：CVE-2026-109618 和 CVE-2026-109619。加拿大网络安全中心将其标记为“php2shell”，并警告所有面向互联网的 PHP 服务——包括 PHP-FPM、mod\_php、php-cgi、LiteSpeed——均处于风险之中。SANS 互联网风暴中心在同一天将信息状态调至黄色（YELLOW），理由很直接：PHP 的部署面太广，PoC 已经在补丁落地前公开流传。

我抓到的这条请求，正是在这个窗口期出现的。

载荷长什么样

Content-Type: multipart/form-data; boundary=----csb1c7df52d34a31bfd     Content-Length: 425     User-Agent: Mozilla/5.0 (compatible; authorized-security-test)     X-Forwarded-For: 121.40.86.84      ------csb1c7df52d34a31bfd     Content-Disposition: form-data; name=”PHPSESSID”
ed40121045168c263a411b0570a1318f     ------csb1c7df52d34a31bfd      Content-Disposition: form-data; name=”PHP_SESSION_UPLOAD_PROGRESS”      |O:6:”Logger”:1:{s:3:”cmd”;s:20:”id;echo CSBTcc6d3a6c”;}      ------csb1c7df52d34a31bfd      Content-Disposition: form-data; name=”f”; filename=”a”     Content-Type: application/octet-stream
Z    ------csb1c7df52d34a31bfd--

表面看，这是一个再普通不过的文件上传请求。但那个 PHP\_SESSION\_UPLOAD\_PROGRESS 字段的值暴露了意图：|O:6:\"Logger\":1:{s:3:\"cmd\";s:20:\"id;echo CSBTcc6d3a6c\";} 是一段序列化对象载荷。O:6:\"Logger\" 声明了一个 Logger 类的对象，属性 cmd 的值是 id;echo CSBTcc6d3a6c。末尾的 CSBTcc6d3a6c 是攻击者用于验证命令是否执行的回显串。

攻击者通过表单字段注入 PHPSESSID，绕过 session.use\_only\_cookies 的限制，指定一个可预测的会话 ID。随后，session.upload\_progress 机制会将 PHP\_SESSION\_UPLOAD\_PROGRESS 的值原样写入会话文件。那个最小的文件上传（filename=\"a\"，内容 Z）只是为了触发整个上传进度处理流程。

这条载荷对应的是哪条攻击链

需要说清楚一件事：这条载荷不是CVE-2026-109618 和 CVE-2026-109619 最核心的利用方式。

根据公开的研究仓库，这两个 CVE 的远程利用链需要处理 ASLR、堆布局和内存破坏。php2shell 的远程链在 PHP 8.4.x mod\_php 上已验证可以拿到 uid=33(www-data)，但条件苛刻：需要控制 memory\_limit 与请求体大小的关系，需要存活的工作进程，还需要处理 ASLR。CVE-2026-109618 的根因是内存耗尽（OOM）时 longjmp() 留下的未初始化内存；CVE-2026-109619 则是全局状态在请求内存释放后未被正确重置，导致释放后使用。

我捕获的这条载荷，走的是更“传统”的路径：会话文件投毒 + 反序列化。攻击者把序列化对象写进会话文件，然后指望目标应用存在文件包含点或者反序列化入口，把这段数据“激活”。公开的复现靶场确实展示了类似的 Chain A：session.upload\_progress 文件名注入配合应用层 LFI，最终执行命令。

所以，这条请求更准确的性质是：低成本试探。攻击者在测试目标是否存在可利用的反序列化链，同时验证 session.upload\_progress 的行为是否符合预期。如果目标恰好有 Logger 类且魔术方法脆弱，那就赚了；如果没有，请求成本几乎为零。

为什么这个时间点值得警惕

PHP 官方在 10 月 20 日预告补丁将于 21 日发布，但技术细节在正式发布前就已经泄露。SI-CERT 的公告提到，发布日期的提前“很可能是因为一些信息已经出现在公开渠道”。GitHub 上的研究仓库在补丁发布当天就包含了完整的分析、PoC 和验证记录。

这意味着，攻击者不需要完全理解 UAF 的堆布局细节。他们只需要把公开的 gadget 链扔出去，看看哪个目标会接住。

如果你也看到了类似的流量

最直接的判断依据是 PHP\_SESSION\_UPLOAD\_PROGRESS 字段的值。正常的进度条场景下，这个值是一个短标识符，不会是 |O: 开头的序列化字符串。

更深一层的缓解措施，在多个安全公告中被反复提及：设置session.upload\_progress.enabled = Off。SANS 指出这一配置“提供了针对漏洞利用的部分缓解”。斯洛伐克 CERT 的公告同样建议，对于不依赖上传进度功能的系统，关闭该选项可以“使至少一种已知的利用方式失效”。

但需要明确：这不是完整修复。CVE-2026-109619 的全局状态问题不依赖 session.upload\_progress 是否开启。加拿大网络安全中心的建议更加直接：立即升级到 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35。PHP 5.x、7.x、8.0、8.1 已经 EOL，不会获得官方更新，只能依赖发行版的反向移植补丁或隔离措施。

那条 425 字节的请求，最终没有在我监控的环境里造成后果。但它是一个信号：漏洞信息泄露后的 24 小时内，扫描器就已经上路了。攻击者不需要成为内存布局专家，他们只需要知道哪里可以扔载荷。

而对于防守方来说，有时候最有效的动作，就是把那个绝大多数网站根本用不上的功能关掉，然后升级。