记一次PHP安全漏洞的马拉松式修复
内容提要
作者盘点家中PHP资产以应对高危RCE漏洞php2shell（含两个CVE，CVSS 9.2）。先关闭session.upload_progress缓解风险，再按资产分类处理：ShowDoc放弃自编译，改用官方镜像并加--pull；WordPress、Nextcloud连带升级应用与PHP；PHP 5.5老项目换用7.4补丁分支自建底座镜像；无法升级的PHP 7.2靠配置加固兜底，废弃机器直接停用。全程由AI执行、人工验收，也踩了不少坑。
延伸解读
先盘点再动手：资产分类决定修复策略
作者没有在漏洞公布后立刻逐台升级，而是先列出所有PHP资产并分成五类：可直接升级、需连带升级应用、只能配置缓解、直接停用、以及重新评估后能曲线救国。这种分类让后续操作有明确优先级，也避免了在无法根治的环境上浪费精力。对读者而言，面对高危漏洞时，先摸清家底比盲目执行命令更重要，因为不同资产的风险和修复成本差异很大。
自编译镜像成本高，上游活跃时优先等待
ShowDoc项目最初尝试自行编译PHP 8.3.36，但国内网络拉依赖困难，编译后还缺扩展，反复测试补扩展耗时很多。后来发现基础镜像webdevops第二天就更新了，于是放弃自编译改用官方镜像。作者的经验是自编译应作为最后手段，上游镜像仍活跃时先等待。此外，CI构建机需加--pull参数主动拉取新镜像，否则缓存会导致升级未生效。
缓解配置只封已知路径，不能替代升级
关闭session.upload_progress.enabled能切断本次漏洞的已知触发路径，但作者强调这不是修复漏洞本身，同一块代码未来可能被找到新的触发方式。因此能升级的环境最终都升到了修复版，只有无法升级的PHP 7.2老服务器才用缓解配置兜底，并配合disable_functions、open_basedir等加固项控制爆炸半径。读者应把缓解视为临时措施，而非根治方案。
AI执行效率高，但人工验收和纠偏不可少
作者用AI执行编译镜像、搭测试环境、跑升级流程，效率明显高于手动操作，但过程中也出现AI验证不相干内容、清理密钥过早、误删测试数据库等问题，需要人工反复纠正。这说明AI适合承担重复性操作，但关键决策、验收和异常处理仍需人把关。对于多资产的安全修复，AI可以降低操作负担，但不能替代对流程和结果的判断。
Q&A
php2shell漏洞的严重程度和影响范围如何？
php2shell包含两个CVE（CVE-2026-109618和109619），CVSS评分9.2，属于未经认证的远程代码执行漏洞。攻击者无需登录，通过构造特定的multipart请求即可在服务器上执行任意代码，触发路径与PHP的session upload progress机制有关。
关闭session.upload_progress能彻底修复php2shell漏洞吗？
不能。关闭session.upload_progress只是切断了本次漏洞的已知触发路径，并非修复漏洞本身。同一块代码未来可能被找到新的触发方式，因此官方强调只有更新PHP版本才是完整的解决方案。对于无法升级的环境，这是一种临时缓解措施。
修复PHP漏洞时应该如何对资产进行分类处理？
文章建议先盘点所有PHP资产并分类：1) 能直接升级到修复版的；2) 需要连带升级应用（如WordPress、Nextcloud）的；3) 无法升级只能配置缓解的（如EOL的PHP 7.2）；4) 直接停用更划算的废弃机器；5) 重新评估后能曲线救国的。分类后针对不同情况采取不同策略。
为什么作者最终放弃自编译PHP镜像而改用官方镜像？
自编译PHP 8.3.36过程折腾，国内网络拉依赖困难，编译后还缺少扩展导致功能异常，需要反复测试补扩展，成本很高。后来发现基础镜像webdevops更新及时，第二天就发布了新版本，因此放弃自编译，回归官方镜像。结论是自编译应作为最后手段，上游活跃时优先等待。
升级WordPress和Nextcloud时需要注意哪些关键点？
WordPress 5.9和Nextcloud 28无法直接运行在PHP 8.3上，需要先升级应用本身。作者的做法是：在本地搭建测试环境，原样跑通旧版本，然后替换文件升级应用（如WordPress到6.8.3），执行数据库迁移，再切换PHP 8.3镜像做兼容性验证。测试中发现主题有PHP8已移除的旧语法，修改后才动生产。数据库升级不可逆，动手前务必dump备份。
对于无法升级PHP版本的老项目，有哪些加固措施？
对于无法升级的PHP 7.2环境，可以采取配置加固：关闭session.upload_progress.enabled，设置session.use_strict_mode=1，并通过disable_functions禁用exec、passthru、shell_exec、system等危险函数，设置open_basedir限制访问范围，调整post_max_size等。但需注意缓解不等于根治，能升级的环境应尽量升级。
使用AI辅助修复漏洞时遇到了哪些问题？
AI执行效率高，但也会犯错：例如派AI验证镜像中的PHP版本时，它跑去验证不相干的内容，需要人工纠正两三次；处理服务器临时密钥时，AI收尾清理过于积极，密钥刚清掉就发现还有任务未完成，不得不重新生成和授权；测试数据库实例也被误删，只能重新导入数据。因此需要人工监督和验收。
