PHP官方确认CVE-2026-109618和CVE-2026-109619为两个CVSS 4.0评分9.2的远程代码执行漏洞，源于内存耗尽处理不当与全局状态残留，影响PHP 5.4及以上所有版本，需立即升级至8.3.8/8.2.20/8.1.29或采取精准临时缓解措施。
不能立刻升级 PHP 版本时，临时缓解措施不是“能用就行”，而是必须精准匹配漏洞触发路径，否则形同虚设。官方给出的配置项有明确作用域和生效前提，改错位置、漏关模块、不重启 worker，都等于没做。
php_admin_value memory_limit=-1 必须在 FPM pool 或 Apache mod_php 配置里设
这个设置不是写在 php.ini 里就能生效的。它必须通过 Web 服务器层强制注入，防止被应用代码用 ini_set() 覆盖。常见错误包括：
- 只改了全局
php.ini中的memory_limit，但没在 FPM pool 的www.conf里加php_admin_value[memory_limit] = -1 - 用了 Nginx + PHP-FPM，却在 Nginx 配置里加
fastcgi_param PHP_VALUE "memory_limit=-1"—— 这种方式会被 PHP-FPM 忽略，不生效 - Apache 环境下没在
.htaccess或虚拟主机配置中用php_admin_value memory_limit -1，而只依赖php_flag，后者无法覆盖memory_limit
post_max_size 和 multipart 边界控制要分层落地
CVE-2026-109618 主要由畸形 multipart 请求触发，单靠 PHP 层限值远远不够。攻击者可绕过 post_max_size，只要请求头或分段结构让 PHP 在解析中途 OOM 即可。必须在三层同时设防：
- Nginx 层：用
client_max_body_size 8m（非上传业务）或32m（含上传），并配合client_header_buffer_size和large_client_header_buffers限制请求头总长 - PHP-FPM 层：在 pool 配置中显式设
php_admin_value[post_max_size] = 8M，且确保php_admin_value[max_input_vars]不高于 1000（防嵌套字段耗尽内存） - 应用网关/CDN 层：如 Cloudflare、阿里云 WAF，启用“multipart 解析拒绝”规则，直接拦截含
filename=""、空字段、超深嵌套名（如a[b][c][d]...）的请求
session.upload_progress.enabled=0 必须全局关闭并重启所有 worker
CVE-2026-109619 的关键触发点是 Session 上传进度功能提前初始化后残留悬垂指针。这个开关一旦打开，就可能在任意请求中激活漏洞链：
立即学习“PHP免费学习笔记（深入）”；
- 不能只在某个站点的
.user.ini里关，必须在全局php.ini中设session.upload_progress.enabled = 0 - PHP 8.5 环境还需额外关闭
fatal_error_backtraces = 0，否则致命错误仍会触发不安全的回溯逻辑 - 改完配置后，必须执行
systemctl reload php-fpm或apachectl graceful，确保所有 worker 进程重新加载——仅 reload nginx 或重启应用服务无效
这些配置只是封堵已知利用路径，不是免疫。比如，memory_limit=-1 能防 OOM 中断，但无法阻止其他内存破坏变体；关闭 upload_progress 可阻断一个 UAF 链，但不能覆盖所有 stale global state 场景。真正风险在于：你不知道攻击者手里还有几个未公开的 PoC 变体。所以，补丁升级不是“后续计划”，而是当前最高优先级操作。
