官方公告里除了升级，还有一组「无法立即更新时」的临时缓解措施。这些措施写得非常具体，但也有非常具体的边界——用错了不但没用，还会制造新的故障。这篇把每一条讲透，包括哪些常见做法其实无效。

一、先记住总原则

PHP 官方对临时措施的定性非常明确：只有更新才是完整解决方案，以下措施仅「减少特定攻击路径的暴露面」，不会让安装变得安全。请不要把「已经配了缓解措施」当成「已经安全了」。

二、针对 CVE-2026-109618（内存耗尽型 RCE）

1. 取消 PHP 自身的内存上限

漏洞的触发条件是「请求触碰到 memory_limit 时数据只初始化了一半」。所以最直接的缓解是让这个上限不再存在，或至少让攻击者无法控制它何时被触顶。

; FPM 池配置（推荐：应用无法覆盖）
php_admin_value[memory_limit] = -1

; Apache 配置
php_value memory_limit -1

关键在 php_admin_value 而不是 php_value：前者只能由管理员在池级设置，应用和 .user.ini 都改不动。同时要回头检查有没有其他池、目录级 .user.ini 或应用代码把有限值又加了回来。

官方也留了一句实话：这消除了「可控的 PHP 内存上限失败」，但底层分配失败依然可能走到受影响路径。所以它是缓解，不是修复。

2. 收紧上传体积与请求规模

; 不需要文件上传的服务
post_max_size = 8M

; 确实需要上传
post_max_size = 32M
upload_max_filesize = 16M   ; 必须小于 post_max_size

更靠前的一道防线是在 Web 服务器或反向代理层限制：解码后的请求体大小、输入字段数量、multipart part 数量、请求头数量、嵌套深度。这里有个细节容易漏：这些限制必须同时覆盖没有可用 Content-Length 的请求，否则攻击者换个传输方式就绕过去了。

3. 用容器 / cgroup 限额兜住可用性

把容器或 cgroup 的内存限制作为可用性边界，并让策略只杀掉受影响的 worker，而不是让整个服务一起挂掉。

这里有一个反直觉但很关键的警告：不要用 RLIMIT_AS 或 RLIMIT_DATA。官方明确说明这会引发同类别的分配失败路径，等于把漏洞直接送到门口。

三、针对 CVE-2026-109619（跨请求陈旧状态 RCE）

1. 关闭上传进度条

; php.ini / FPM 池 / 服务器配置
session.upload_progress.enabled = 0

改完必须重启所有 worker。官方还特别说明：这条要写在 php.ini、FPM 池或服务器配置里，在请求解析前生效；不要依赖 ini_set() 或 FPM 的 .user.ini——它们生效太晚，挡不住已确认的攻击路径。

同时要清楚它的范围：这条只封住了已确认的 session 路径，不覆盖其他变体。

2. PHP 8.5 上关闭致命错误回溯

; 仅 PHP 8.5+
fatal_error_backtraces = 0

同样需要重启所有 worker。官方明确：这只能挡住已确认的致命回溯路径。

3. 清理会在初始化前输出诊断信息的配置

移除那些「按请求生效、会触发弃用或错误提示」的设置。这类输出的时机恰好落在状态尚未正确初始化的窗口里。

但请注意一个常见的无效动作：用 error_reporting、display_errors 或 @ 把诊断信息藏起来，是没有用的。官方写得很直白——隐藏信息不改变状态是否被正确初始化。

4. 修掉能被攻击者触发的致命错误与超时

这是这一条里唯一真正属于「治本」的动作：把回调、上传/导入处理、清理阶段这些路径上的致命错误与执行超时修掉。因为漏洞一的前提就是「致命错误发生在错误的时机」，那么能触发的致命错误越少，攻击面就越小。

四、什么情况下必须停机

下面几种情况，建议直接安排停机窗口，而不是硬扛临时措施：

  • 你的站点直接对公网提供 PHP 服务，且 mod_php 形态 —— 官方明确说明这是风险最高的一档。
  • 站点在漏洞窗口期（10 月 21 日之前）已经对外暴露过 —— 升级不能修复已发生的入侵，需要留出排查与恢复时间。
  • 临时措施需要「重启所有 worker」才能生效，而你当前没有低峰期窗口 —— 那就把重启放进停机窗口一起做。

五、这些做法没有用（请直接跳过）

  • 只装 WAF：官方与多国 CERT 反复强调，WAF 单独不足以构成保护，它只是限速与隔离层。
  • 用 ini_set() 或 .user.ini 关 upload_progress：生效时机太晚，挡不住已确认路径。
  • 用 error_reporting / display_errors / @ 隐藏报错：不改变初始化时序。
  • 用 RLIMIT_AS / RLIMIT_DATA 限制内存：会主动制造同类分配失败，等于帮忙触发漏洞。
  • 只升级了 CLI 版本：网站跑的是 FPM，升级必须落在站点实际使用的那一套二进制与配置上。

六、优先级建议

如果资源有限，按这个顺序做：

  1. 升级到修复版本——这是唯一完整解，其余都是为它争取时间。
  2. 如果 24 小时内无法升级：关掉 session.upload_progress、收紧 post_max_size、在代理层限制请求规模，并重启 worker。
  3. 同步做一次入侵排查（见《升级完成不等于结束》一文），确认窗口期内没有被动过。
  4. 把这次事件的排查结果沉淀成一份版本台账，下次同类事件能直接圈出影响面。