10 月 21 号 PHP 一口气发了 8.5.12、8.4.27、8.3.36、8.2.35 四个版本，修的是 CVE-2026-109618 和 CVE-2026-109619，就是外面叫 php2shell 的那两个，未认证远程代码执行，发布前一天的预告里写的是 CVSS v4.0 9.2。这事要是落在 8.3、8.4 上，升个小版本、重启一下就完了。麻烦的是那种谁都不敢碰的老站：7.4 写的，扩展一堆，作者早就离职，迁移排期写在明年。
官方公告里有句话挺不客气的：There are no complete mitigations, updating is the only safe choice. 没有完整缓解，升级是唯一安全的选择。所以下面说的都只是迁移前少挨点打的办法，不是解决方案。
版本这块别搞错
- 修复版就是上面那四个。8.1 以及更早的版本，PHP 项目已经不再给更新了。
- 不过这次因为太严重，安全团队给 7.4、8.0、8.1 放了最小化的源码回移补丁，给自己从源码编译、又没有 LTS 厂商的人用。用发行版包的，去问发行版或者 LTS 厂商有没有回移，别自己猜。
- 影响面是所有处理 Web 请求的 PHP：PHP-FPM、Apache mod_php、php-cgi，还有 FrankenPHP、LiteSpeed。官方认为 mod_php 风险最高。别以为换成 FPM 就没事。
- CISA 已经在 10 月 26 日把这两个 CVE 收进 KEV 目录，也就是确认有在野利用。
顺手提一句，8.2 虽然这次有补丁，但支持版本表上它的安全支持只到 2026 年 12 月 31 日，还剩两个月。要迁的话直接往 8.3 以上迁，别迁到 8.2 再迁一次。
升不了的这段时间
CISA 的告警对这种情况的建议是：升不了的，或者还在用 8.1 及更早不受支持版本的，先把 PHP 系统下线，等补上再说。很多人第一反应是不可能，但真去问业务方，有的后台一周也没几个人登录，先关掉或者只允许内网访问，没那么难谈。
实在关不了，下面这些能做一点算一点：
- 先盘点：机器上
php -v只是起点，宝塔这类面板、Docker 镜像、某些商业软件里打包的 PHP 都算。CISA 也提了 PHP 经常藏在别的软件里面，不一定看得出来。 - 先处理公网的：内网工具往后排，挂在公网上的老站优先升级、迁移或者收口。
- WAF 只能挡一部分，CISA 的原话是 may provide some protection，别指望它兜底。
- 盯进程：PHP worker 去拉起 shell、下载工具，这种行为要有告警。CISA 告警里还给了 SIGMA 检测规则，可以对着自己的日志源看看能不能用上。
- 临时配置：PHP 的安全公告里给了几条针对具体攻击路径的配置，比如调内存上限、压低
post_max_size、关掉 session 上传进度。官方自己也说，这些只能缩小暴露面，版本里的洞该在还在。
那个 session.upload_progress
10 月 23 号官方又补了一份 informational advisory，oss-security 上也转了，对应 CVE-2026-115560，建议下一个常规 bugfix 版本出来之前先这么设：
session.upload_progress.enabled = 0
这一项正式修复还没发，官方说会跟下一个常规版本一起出完整公告。触发条件比较偏，需要特定的 serialize handler 配置再加运行时切换，官方自己也说实际中不太可能遇到。但这个开关本来就在 CVE-2026-109619 的缓解列表里，老站多半用不到上传进度，关掉基本没成本。注意要写在 php.ini、FPM pool 或者服务器配置里，别用 ini_set() 或者 FPM 的 .user.ini，改完把所有 worker 都重启。
Windows 上用 PHP 的还有一件事：10 月 26 号官方重打了带 -1 后缀的 Windows 包，修的是 Brotli 的 CVE-2026-111497，开了 cURL 自动解压才会碰到。这个洞 Node 那边也中了，之前那篇 Node 18 Brotli 的帖子里有讨论。
想问问手上也有 7.4/8.0 老站的，你们是自己打官方的回移补丁，还是走发行版或 LTS 厂商，还是干脆借这次把迁移排期往前挪了？