【歪门邪道】PHP CVE大逃杀

虽然文章分类是歪门邪道系列，但实际上是最正经的一次，这次没有任何野路子。

大逃杀

想必全世界的运维对10月21日都记忆犹新，尽管安全隐患并不全是这一天发现的，但这天晚上依旧扣人心弦。

事情的起因是PHP官方发布了Security Advisory（安全建议），说他们发现了两个可以实现RCE的CVE，尽管没有公布细节，并且目前没有发现在野利用，但从危害性来说已经足够吓人了。两个不同的漏洞都允许黑客通过发送请求的方式取得访问权限，再配合前阵子发现的Linux内核虚拟机逃逸漏洞，或者配合什么暂未公开的容器逃逸漏洞，翻译过来就是别人可以发几个请求拿下你的服务器。而网络上也流传了一些缓解方案，但这些缓解方案只是减小了攻击面，不能完全阻止攻击。PHP官方说21日晚上10点（北京时间）发布源码补丁，推荐大家尽快更新。

为什么要尽快更新呢？因为得益于AI的发展，以前需要安全专家和资深黑客才能做到的事情，现在虽然一个阿猫阿狗用AI就能做了。这也意味着通过发布的补丁反推出漏洞细节，并快速完成攻击方案，不再是高门槛的难事。AI就好比枪，你把枪给一个普通人，也许不会造成什么太大的伤害，但如果你把它给一个猴子，那谁也说不好会发生什么事情。而在安全领域，猴子有枪这种事情越来越常见了。
当然，我不是说应该管控AI并限制大家访问AI，我一直认为开放访问是非常重要的。尽管会造成严重损失，但这种损失完全可以避免。不能因为自己的防御工作没做好，就把全部责任指向攻击者。当然，这也不是说攻击者就没有责任，非法访问服务器就像闯入没有锁门的屋子，人家没锁门是人家的不对，但你不能进人家屋子。

当然，事情还没有结束，隔壁NodeJS也发布了安全更新，差不多的时候由听说LiteLLM又双叒叕遭受供应链攻击，新版本包含恶意代码会偷用户凭证。不光如此，还没完，印度一个CA的中间证书私钥泄露，泄露后大家发现他们的私钥有效位严重不足。通常来说他们使用的签名算法，私钥384位，要求有效位至少256位。eMudhra用的什么呢？4。对，就一位数字4。比4好一些的还有56、115、66、155、156、230 和 237。于是我们有了新的年度笑话：

--- BEGIN PRIVATE KEY ---
4
--- END PRIVATE KEY ---

私钥泄露意味着任何人都可以利用泄露的私钥签发TLS证书，从而欺骗还在信任这些证书的系统，完成流量劫持与中间人攻击。对于运维方面来说，维护人员必须尽快吊销系统内相关CA的证书。有些软件会从操作系统读取信任链，因此更新系统就可以完成吊销；但有些软件有自己的信任链，需要软件更新；而更绝望的事情是，有些编程语言内置了可供信任的CA，因此必须要更新工具链或运行时才行，例如Go，NodeJS，Rust和Java。

你以为故事就此结束了？我们Java当然也不甘示弱，Oracle和OpenJDK都发布了Security Advisory，其中最严重的CVE有7.5分（后来的9.1分的CVE是对应的CA中间证书私钥泄露），就在我准备睡觉的时候，听说Chrome和Chromium也爆出沙盒逃逸的CVE。那还能怎么办呢？睡觉呗。

当然，对于企业运维来说，这还不是最坏的。前几天PingCAP被人脱裤，TiDB的源码和数据都被一锅端了。于是便有了这个运维笑话/恐怖故事：

让我们想象一下你司架构是 NGINX v1.23.0 作为边缘节点，后面挂着 PHP-FPM 7.3 (刚花了几周时间从 5.6 升级上来) 的源站 + 前段时间刚花了大价钱采购来的 TiDB NewDB + Node.js 24 LTS Brotli 中间件，开启了 Brotil 压缩功能、Go 作为对外访问的网络沙箱、使用 Python + LiteLLM AI 企业内部 Harness 工具 (CI 昨晚刚从 PyPI 拉了新包并推送到了生产环境，现在全公司电脑都装上了这套 Harness)、公司服务器全部跑在 Linux 内核 c6e50df8 之前、网站的 HTTPS 证书由公司前段时间刚采购的无保险低价 Sectigo DV 证书（还没上 ACME 自动签发）、公司的 Vyper 智能合约部署在 Docker 29 + Kubernetes + Traefik Ingress 上开着 mTLS fail-open，宿主机还跑着 ASP.NET Core 面板和 .NET 本地服务、公司的软件和外发机密文件通过 emSign 代码签名，根证书库用 Go crypto/x509 + Rust webpki-roots + Python certifi
而你，是这家公司的核心 on-call 运维。

幸好我在今年6月给服务器升级的时候顺便换成了容器化部署，从而摆脱了对LNMP脚本的依赖，不然这次安全更新还要捏着鼻子用脚本编译安装新版PHP，想想都头疼。这也侧面印证了一个事实：再麻烦的维护，只要事先安排好，总要比被迫进行的好。

更新PHP

好在我受到影响的服务只有这个博客。因此只要更新PHP就好了，容器化部署意味着只要包含修复的php容器构建好了，直接docker compose down然后再up就好了。但这个过程也并非一帆风顺。

21日当晚，PHP新版本如期发布，但发布的是源代码。而docker上的php镜像由Docker Community维护。从PHP发布源码，到Docker Hub上php镜像可用，社区用了整整两个小时。期间我也想过要不要自己构建一个镜像算了，后来想想这种临时起意还是不要的为好，万一哪一步搞错了，造成更大的伤害就得不偿失了。虽然已经提前部署了缓解措施，但还是因为害怕服务器被入侵，我在10点钟发布补丁后关闭了服务器的php容器，因此博客主站也同步下线了两个多小时。

当然，等镜像更新也不安生。首先我将服务器的SSH访问权限授予了GLM 5.3（在OpenCode中，由Synthetic.new托管，不需要担心信息泄露），让它搜索关于这两个CVE的信息并检查服务器是否有被入侵或利用的痕迹。我的Synthetic订阅包含DeepSeek V4.1 Flash 1017，GLM 5.3（还有Flash）和KImi K3。为什么不用K3呢？太贵了。为什么不用DeepSeek呢？感觉不如GLM 5.3靠谱，毕竟之前HuggingFace被入侵，他们也是选择用GLM系列（当时是GLM 5.2）进行分析。总之，经过GLM 5.3的搜索（主要是看访问日志），并没有发现和CVE披露的攻击模式相同的请求，后来经我验证后确认安全。

之后就是刷群聊，突然看到有人说新版本并没有完全修复CVE，并提供了一个PoC，宣称新版本的PHP并未完全修补好CVE，新版本仍然可以实现RCE。我一看，这不对啊，补丁一定要能修补漏洞。后来觉得事情有些蹊跷，因为只在tg群组和频道中口口相传，而GitHub和Reddit上完全没有讨论。于是基于让GLM 5.3看了一眼，GLM 5.3构建了一些镜像，在本地跑了一下，最终发现这个PoC宣称的漏洞实际上是序列化配置错误引发的问题，这个在PHP文档中早有警示，和修补的两个CVE完全不相关。得出结论后和一个频道主短暂交流了一下，他也确认这个是假消息，而原频道也是公认的AI Slop粪坑。What can I say？后来22号早上看新闻的时候也有声音说大家对于AI的报告缺乏判断力，我在几个群里也都说了PoC是无关的，但比较令人遗憾的是，大家还是觉得PHP版本升级了也没用，反正问题都没修好。

所以这也是为什么之前我说猴子拿枪。另一篇报道说源码补丁出现之后，GitHub上涌现出了无数与这两个CVE有关的PoC仓库，但没有一个是能用的。而大多数仓库宣称自己实现了PoC，前提也是服务器本身有配置错误，例如先前那个反序列化错误。
又联想到最近Steam新品节也有很多AI slop，原本设想的是AI能够补足开发者的短板，让小规模的开发者也能有能力做出优秀的游戏。结果AI普及之后发现，AI是这个开发者最长的板，那还说啥了，vibe coding路边一条。