PHP2Shell 是什么。
简单说，是 PHP 引擎层两个内存漏洞的绰号。CVE-2026-109618 和 CVE-2026-109619，十月二十一日的版本修掉了。
单独拎出来讲，不是因为 9.2 分。是因为它根本不在你写的代码里。
这两个洞在请求收尾阶段
PHP 是 shared-nothing 的，一个请求一套状态，结束时清干净。问题就出在这个“清”上。
内存分配失败之后，清理代码去处理一个没初始化完的状态，碰了未初始化指针，释放了没分配的对象。另一个是致命错误打断了清理，内存放掉了、指针还留着，下一个请求读到旧指针。
可以理解为：门关上之前没把灯关对，下一个人进来摸到了上一任留下的东西。
“应用代码写得干净就没事”这次不成立
这是整件事里最反直觉的部分。
漏洞在引擎。请求进你的 index.php 之前，它已经在跑了。Apache 配 mod_php 的组合下，攻击先于应用代码执行，不需要认证。你代码审得再干净也拦不住。
评论区有人惊讶。我理解这个惊讶，但这事本身不新鲜，只是大家习惯把安全边界画在自己的项目目录里。
9.2 分先放一边
CVSS 4.0 给的是 9.2，攻击复杂度评的是 High。这两件事同时成立。
Rapid7 审过的公开 PoC 只对特定操作系统、特定 PHP 版本、特定 Web 服务器组合有效。还谈不上普遍可靠利用。“任意 PHP 服务器都受影响”，太满了。
风险最高的是 mod_php。PHP-FPM 在启动失败时会直接终止 worker，OOM 那条触发路径就被堵掉了。
2200 万暴露实例、69.3% 的份额，数字是真的。但它说明的是这块地大，不是你家已经着火。这两件事老被混着讲。
真正该看的是时间线
2024 年 Quarkslab 做审计，核心开发者第一次注意到 OOM 那边的迹象。当时没有已知利用路径。
然后就停在那儿了。
停的原因不神秘。竞争补丁之间的兼容性、修本身可能带来的拒绝服务风险、第三方扩展受影响。PHP Foundation 把延迟归到安全团队的决策流程和资源不足上，说是结构性问题。
2026 年 8 月，Calif、OpenAI、Wiz 又报了一次，这回带了可用的无条件 RCE。
两年。不是没人看见，是看见了没推动。
补丁还没发，编号先漏了
十月二十日，编号提前两天出来。Chainguard 的镜像在补丁发布前就已经带了修复。
embargo 又破了一次。这个“又”字不是我加的，这类事这几年不算少。
补丁最终在十月二十一日 14:00 UTC 发出。修复版本是 8.5.12、8.4.27、8.3.36、8.2.35。8.1 及更早没有常规上游发布，7.4、8.0、8.1 有有限的源码 backport。
升级完不重启，等于没升
这条是我想让所有人记住的一条。
已经跑着的 worker 内存里还是旧代码。磁盘上的文件换了，进程不知道。不重启或者不优雅重载，你面前就是一台补丁打好了但依然脆弱的机器。
容器也一样。基础镜像得重建，别指望旧镜像里的东西自己变。
还有个坑：发行版可能 backport 了修复，但不改上游版本号。php -v 显示的还是老版本，看着像没修。得去看包的 changelog 或者 advisory。
顺带说一句，memory_limit=-1 出现在指引里，别把它当保险。Rapid7 认为分配失败仍然可能走到漏洞路径上。RLIMIT_AS 这类限制也可能反过来触发分配失败。容器的 cgroup 内存限制不完整，搞不好直接把整个 worker 池杀掉。
临时缓解能做的是关掉 session.upload_progress.enabled，PHP 8.5 上关掉 fatal_error_backtraces，post_max_size 压到 8M，前端限制 multipart 大小。这些是撑时间用的，不是解法。
还有，别用 display_errors 或者 @ 把错误藏起来。日志安静不代表状态是安全的。
AI 那条我只看懂一半
有观点认为，AI 把从读公告到发起尝试的成本压下来了，补丁 diff 本身也给模型提供了定位线索。
另一面是公开 PoC 还不稳定。内存破坏这类利用，可靠性一直是难点，给特定发行版构造堆布局没那么容易。
这两句我信，但我没有自己验证过任何一头。先放在这里。
顺带一提，PHP Foundation 自己在安全工作里也用 AI 做扫描和验证，最终判断和补丁还是人在做。这个分工我觉得挺合理。
CISA 在 10 月 26 日把两个 CVE 加进了 KEV。按 KEV 时限安排修补，比自己拍脑袋定优先级靠谱。
本周就这些。
上面有任何一条你试过、或者觉得我讲错了，欢迎告诉我。尤其是那条重启的，你要是知道哪个部署方式容易漏，更欢迎。
下周见。