eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC

解决什么问题

大量 PHP 部署默认开启 session.upload_progress.enabled，而 2026 年泄露的两个 CVE 正是把上传进度机制变成了可直接在 Web 服务器上执行命令的预认证 RCE。安全团队真正需要知道的是：自己那批机器到底能不能被利用、官方紧急版本有没有修干净。一段堆 UAF 的漏洞描述回答不了这个问题。这个仓库把可用的利用链和补丁、检测指引放在了一起。

有什么不同

通用漏洞扫描器只会读版本号。这个 PoC 走的是完整的四阶段 HTTP 攻击：先通过中止请求强制 prefork worker 轮换，再用超大多部分字段触发 OOM，从 Set-Cookie 侧信道泄漏堆基址和 libphp.so 基址以绕过 ASLR，最后在 167 字节的 zend_string 里伪造 HashTable，把 pDestructor 指向 zif_system。这种端到端的利用工程通常只出现在 Metasploit 模块或专门的漏洞研究文章里，而且它还附带了配置缓解、WAF 规则、源码补丁和子进程检测建议。代价是目标条件很窄：默认 profile 假定 Apache prefork 下的 mod_php、单 worker、memory_limit 远低于 OOM 触发值，内联命令上限 14 字节。

适合谁

适合负责公网 PHP 资产的安全运营分析师、应急响应人员和平台工程师，用来在关闭补丁窗口之前拿到可利用性的实证；也适合渗透测试人员验证客户暴露面。只想找通用 PHP 加固指南的读者应该去看别处；任何人都不应把它对准自己无权的系统，因为它既没有许可证，也没有明确的授权框架。

上手成本

运行 poc_109618.py 需要 Python 3，目标要符合 README 声明的 Apache prefork + mod_php 配置，可靠绕过 ASLR 还依赖发行版相关的符号偏移（文中提到 Debian Bookworm、Ubuntu Noble、Ubuntu Jammy）。README 异常长，把运维建议和利用细节混在一起，而且未声明许可证，商业或内部再分发在法律上存在模糊地带。PHP 5.x/7.x/8.0/8.1 已 EOL，没有上游补丁，项目只能依赖配置层缓解。它应被看作绑定这对特定 CVE 的短期工具，而不是长期维护的平台。

点评

项目才 3 天，已约 980 star，日均约 287，这是典型的新 CVE PoC 爆发式增长，而非成熟安全工具。它是否持续有用，取决于上游偏移和利用代码能否在 PHP 8.2 到 8.5 的紧急版本发布后继续成立。这个增速说明当下防守方的关注是真实的，但没有许可证、用途单一，意味着你应把它当作情报材料来读，并在自己的实验环境里核验每一条结论后再用于实际事件。它是及时的产物，不是长期依赖。