CVE-2026-109618

成因与利用条件

PHP 通过 longjmp() 从 OOM 错误中退出当前上下文；某些请求阶段已经能访问尚未完整初始化的 request state
分配失败后，错误清理过程可能把无效状态当作有效状态读取或分支处理，形成内存破坏并进一步 RCE
Multipart 请求可能通过以下方式触发内存压力：
- 没有可用 Content-Length 时持续提交解码后的 body
- 单个 multipart part 包含大量 header，内存表示远大于线上的数据
- 空文件控件、嵌套字段和大量 input variables 造成内部数组膨胀
- 应用或扩展对攻击者输入执行大规模分配
表面满足 post_max_size 不代表不会发生 OOM；解码后的大小、header 数量和内部表示也要限制

text

未认证 HTTP 请求
  → multipart / 其他输入导致 PHP OOM
  → longjmp() 提前退出
  → request state 未完成初始化或清理
  → request shutdown 使用无效状态
  → 内存破坏 / RCE

运行方式	公开证据与限制
Apache `mod_php`	PHP 安全团队和研究方报告已演示未认证 RCE，触发可早于应用代码执行；默认输入和内存限制的普通 prefork 配置也在演示范围内
PHP-FPM	源码分析认为存在风险；请求启动失败会退出 FPM child，阻断该特定启动期链路，但启动成功后的其他 OOM 路径仍需评估，本编号没有据此宣称完整 FPM exploit
FrankenPHP	维护者认为其无条件调用 request shutdown，可能存在应用无关路径；具体部署待验证
LSAPI	行为类似 FPM，应用相关路径属于待验证

PHP 8.5 分支共同修复 commit：31c0ea7d7ff1d1fccb6492e52dab544011628065，标题 Avoid state corruption via bailout，同时修复本 CVE 和 CVE-2026-109619
补丁将不安全的 OOM bailout 改为延迟 soft OOM，在更高 hard limit 触发时直接退出，并重置可能在请求初始化前被访问的全局状态
PHP 项目为 7.4、8.0、8.1 提供了最小源码回补；发行版或 LTS 厂商可能另有回补，不能仅按上游版本号判定
memory_limit=-1 只移除可控的 PHP memory limit 失败，底层分配仍可能失败；它不是完整修复且会改变资源边界
不要使用 RLIMIT_AS 或 RLIMIT_DATA 代替修复，它们可能主动制造触发漏洞路径的 mmap 分配失败
可临时降低部分风险：限制代理和 Web server 的解码后请求体积、multipart part/header 数量、字段数和嵌套深度；不使用上传时可在前端阻断 multipart
关闭 session.upload_progress.enabled 主要针对关联漏洞路径，不能完整缓解本 CVE

PHP 官方和 Datadog 均声明存在未认证 HTTP RCE 演示；本笔记未独立运行验证
公开候选仓库：Zer061/CVE-2026-109618，固定 commit 8508dbc910609e78cd8475bd3dd34b1c65585a66；其中的脚本只作为资料入口，不代表代码有效或安全
观察线索：异常 multipart、大量表单输入、请求初始化期 memory exhaustion、重复 HTTP 500、PHP worker 异常退出，以及 PHP/Apache worker 派生 shell
成功利用不一定造成崩溃或留下应用日志；单个线索不能证明利用
host-checker --integrity-only 只能检查 APK 文件完整性，不能确认 PHP Web SAPI、容器或运行中的 worker 是否修复，也不能判断是否已经利用