php官方针对本次漏洞的部分已知攻击路径，给出了几个临时缓解方案，但官方明确说明，这些临时配置绝对没法保证系统完全安全。调整配置的核心作用只是尽可能缩短漏洞暴露的时间窗口，彻底修复还是得等打了官方补丁的php版本上线，把所有运行中的进程全部替换完才行。
先给临时措施设置明确的结束条件
遇到紧急情况时，调整配置确实能挡住一部分已知的漏洞触发路径，但绝对不能拿临时配置当借口，拖着不升级打补丁。每做一次临时配置变更，都得明确对应负责人、生效范围、对业务的影响，还有清晰的撤除条件，这个结束条件就是所有带补丁的进程全部上线，业务验收通过。
这次涉及的两个漏洞，触发对应的PHP生命周期环节完全不一样：一个是内存不足的处理逻辑，可能提前跳出还没完成初始化的上下文，后续清理阶段又误用到了异常状态；另一个是跨请求全局引用，旧请求的内存已经释放之后，后续新请求还能访问到这块地址。你就算关掉了某一个触发入口，也只能打断部分已知路径，完全没法证明其他业务操作、第三方扩展里不存在同类问题。
立即学习“PHP免费学习笔记（深入）”；
关闭上传进度：仅覆盖已确认的相关路径
官方给出的建议是，暂时没法升级的话，要修改请求解析前就生效的全局配置，把上传进度功能关掉，之后必须把所有PHP工作进程全部重启。注意写在业务代码里的运行时配置生效时机太晚，FPM的用户级配置也不能当这条攻击路径的可靠防护手段。
; 临时措施：在合适的启动配置中设置，并替换全部工作进程 session.upload_progress.enabled=0 ; 仅适用于 PHP 8.5 的已确认回溯路径，不能覆盖其他状态问题 fatal_error_backtraces=0
关闭上传进度，可能会影响那些靠这个功能做上传进度条展示的业务，改之前一定要先核对前后端的相关逻辑。就算改完之后文件上传功能本身还能正常用，也绝对不能跳过后续打补丁的步骤：这个配置只是减少了特定异常状态的生成和调用，根本没把PHP解释器里所有内存相关的问题修好。
内存与请求限制需要同步评估
官方提到，实在没法升级的场景下，用管理员级别的配置强制取消PHP自身的内存上限，能减少一部分可被控制的内存不足触发路径。但这么做也有明显缺陷：底层内存分配失败的场景还是可能触发漏洞，而且取消内存上限之后，资源占用的风险会大幅升高，必须由清楚主机资源上限的运维人员评估之后才能操作。
别随便抄一行取消内存上限的配置就直接把服务挂公网上跑。改完这个配置之后，你还得同步检查容器、cgroup的资源边界，请求体大小、表单字段数、分段数量、请求嵌套层级这些限制项，也要评估异常请求会不会影响同主机其他业务的可用性。官方特别提醒，绝对不能用那些会诱发底层内存分配失败的地址空间、数据段限制，来当漏洞的临时防护方案。
| 场景 | 过渡方向 | 仍然不能证明 |
|---|---|---|
| 完全不需要上传 | 评估在前端阻断相应请求类型 | 所有状态路径都消失 |
| 必须支持上传 | 缩小请求范围并验证业务 | 解释器已经完整修复 |
| 无法确认配置生效 | 优先限制访问或隔离 | 页面正常就是安全 |
清理旧配置与错误路径，不能只隐藏报错
删掉那些会在请求初始化前就触发诊断的失效配置，逐一检查所有公网能直接访问的致命错误页面、超时配置、上传和文件导入路径。要注意，隐藏错误提示和修复漏洞完全是两码事：你就算把错误输出关得严严实实，也挡不住攻击者访问解释器内部的异常状态。
- 核对当前环境实际加载的配置文件、FPM池级别的覆盖配置，确认所有设置都真的在目标环境生效。
- 在受控的测试环境里跑一遍全量业务验证，摸清楚资源边界，把这次临时措施对业务的影响全部记录下来。
- 全部工作进程替换完成之后，还是得继续推进补丁升级，绝对不能把临时配置生效当成漏洞已经完全修复。
只读审计：脚本只输出事实，不做安全保证
<?php
// 只读取配置，绝不输出“安全”判定；当前进程不代表其他池。
$report = ['runtime'=>PHP_VERSION,'sapi'=>PHP_SAPI];
foreach (['memory_limit','post_max_size','upload_max_filesize',
'session.upload_progress.enabled','fatal_error_backtraces'] as $key) {
$value = ini_get($key);
$report[$key] = $value === false ? '(unavailable)' : $value;
}
$report['conclusion'] = 'mitigation settings are not proof of a complete fix';
echo json_encode($report,JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;
把这段代码存为 mitigation-readonly.php 直接运行就行。这个示例是在本地PHP 8.5.10 WebAssembly环境下验证过的，运行过程不会修改任何配置，也不会执行内存耗尽测试。记录结果的时候，一定要把配置值和对应的运行环境一起存，别把A进程池的审计结果套到另一个进程池上。
四个必须及时纠正的常见误区
- 觉得关掉上传进度就永久安全：这个配置只能覆盖对应的单条路径，根本挡不住其他触发方式。
- 觉得取消内存上限之后就能放开流量随便跑：资源耗尽、底层分配失败的风险依然存在，必须逐一评估。
- 觉得日志里没异常就不用升级了：没抓到相关错误日志，完全不能证明漏洞没有被触发过。
- 临时配置散落在各处没人管：统一登记所有配置的生效层级，打完补丁之后再根据业务需求逐一复核要不要回滚。
要是你没法确认临时措施的覆盖范围、也没法证明配置真的生效，优先先把服务从公网收回来做隔离，联系PHP版本的维护方处理。实打实的隔离操作，比没经过验收的“我已经改完配置了”这种说法靠谱得多。
