这次PHP出现漏洞修复发布已经过去超过一天半的时间了，有了一些思考和想法，来复盘一下整个事件的经过，说一说自己的想法，还有一些小小的反思。
事情最开始，大概在前天（修复发布当天）早上11点前后的时间，在一个群里看到有人发了一张截图，内容是关于这次漏洞修复的预告，大概是这样：
一开始的时候，我其实并没有很在意，甚至觉得这事儿好像没什么大不了的，该干啥干啥，吃好睡好最重要，虽然我也维护着那么几个用PHP的老系统，PHP遇到漏洞和问题太常见了，似乎没有什么值得大惊小怪的，当时就想，那过几天想再想起这事儿的时候去更新一下PHP版本就万事大吉了。这个时候，我也没有那么重视这件事，已知的信息很少，中午的时候有人问我，我还这么说
但慢慢地，这个消息越来越多次地出现在我的面前，在越来越多的社交平台或网站上反复看到类似内容，论坛里也出现了关于这次事件的讨论，比如…
甚至一些服务商也开始提示风险，到这，心态就发生了变化…然后遇到了火上浇油的说法：
套了 CF，扫 IPv4 的话，不到办个小时就能扫完全网
不过就算到了这时候，我的想法(和别人讨论的时候说的)还是 仔细想想我觉得其实可能没那么严重，如果真的严重到需要把站点都停下来的地步，那官方发布的修复应该不会忽略8.1及以下版本，不过同时也开始更多的了解相关的信息。当时给运维说：“把 session.upload_progress.enabled 关掉，晚一些更细PHP版本”。
再然后，再然后，看到了很多站点预告了维护，甚至有的站点直接关机了，其中不乏一些平时关注的比较大的站，再然后需要维护的其中一个系统的一个客户说，哎，听说PHP有这个漏洞啊，我听说**(其他站)已经关机了，我们要不要也关？
这一刻，问题的性质就变了…我不再是可以轻松应对的人了，一边安抚客户情绪，一边规划时间，晚上蹲点第一时间更新变成了必须完成的事。
时间来到下午 6 点，收到了这样一个东西：
这东西冠上了 POC 的名头，但当时官方还没发布修复，然后仔细看了看，很明显这不是同一个漏洞，我是这么说的
不过，很快消息传来，有其他人复现这个 “POC” 成功了，嘶~~此时我也有了，要不关站的想法（最后还是忍住了）。
既然提到了这个仓库，这里就先说说题外话，我没啥能力，懂的很少，实际也没做什么，不配公开评价他人，但现在这个仓库是这样的，实在是有点…哎…
然后，就到了晚上更新的时候了，思考下来，盯源码是最快获取更新的办法，嗯，然后，很快等到了源码更新，那这时候第一时间应该做什么呢？没错！当然是交给AI分析，然后发个帖子了。。。（略略略！）
在修复发布半小时后，PPA 还没更新，版本迁移验证还没做，一旁看修复的AI也给出了事态非常严重的结论，于是，根据AI 的建议调整了nginx的配置
client_max_body_size 1m;
if ($http_content_type ~* "(multipart|boundary)") {
return 415;
}
fastcgi_request_buffering on;
然后现场让AI改造文件上传和数据提交接口，放弃了所有 multipart 的上传。
再之后，就是平平无奇的更新了，就不具体说明了。与此同时，看到了各种漏洞像雨后春笋一般冒了出来（得益于印度老哥的证书，大家几乎都没能幸免于难），各种梗图和段子，看得我也是很开心。
再之后就到了刚刚，忙完了各种乱七八糟的事情，有时间来具体看看这个漏洞怎么回事儿，顺便看看网上到底有没有可用的 POC 了，然后发现有挺多自称是这个漏洞的POC，都是之前那个反序列化漏洞问题带来和演生的，和这次 109618/109619 ，除了都是同一个模块上的漏洞之外，似乎没啥太大的关系。不过还是找到了一个实际有效的（eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC）在我看的众多号称针对这个漏洞的POC中，只有这一个是我认为真正匹配这两个漏洞的。
在此之前，我并没有特别仔细地去分析这个漏洞，只是看了AI所给我阐述的内容，大概有了一些了解，让AI为我确认没有利用POC名头投毒后，就想直接尝试执行，用本地还没更新的开发环境试试，看看效果总是没问题的。
看了看这个POC，它的配置的主要内容大概是这样的：
ZIF_OFFSET = 0x43A870 # zif_system
DTOR_OFFSET = 0x613C50 # ZVAL_PTR_DTOR (zval_ptr_dtor)
HTDATA_OFFSET = 0x6E0D8 # live 167-byte string used as fake HashTable
MAX_CMD = 14 # 167-byte carrier - 0x98 header - NUL
BOOKWORM_STAGE1_N = 841
BOOKWORM_STAGE2_T = 406
BOOKWORM_STAGE2_V = 16
BOOKWORM_HTDATA_OFFSET = 0x690D8
BOOKWORM_STAGE3_PADS = [(31, 31)] * 6
SID = b"attacksessionid0001"
DEFAULT_CMD = "id>/out/p1"
然后我愣住了，我本地的版本和他的演示的版本不一样啊，我毫不怀疑，根据这个POC和对应的容器环境，能够复现，但我本地的环境是 nginx 搭配 php-fpm，和POC的针对libphp.so完全不同…仔细想想，我也没能力靠自己完成改造实现漏洞的利用和验证…
zif_system是这个POC里使用了PHP的system/eval函数用一种最简单的办法实现验证和复现，php服务的内存基址在读Zend MM的指针遗留可以直接读到，但zval_ptr_dtor的偏移量不是能直接得到的，只能依赖对版本的提前分析。每一个PHP版本，每一种编译参数，优化方案都会带来不一样的地址，偏移量但凡错一点，可能出现的就不是获取到shell，而是干崩服务了，想要实现高阶的利用，这个哈希表也要精心的设计和计算……
哦，对，上面这些是我根据我的理解给出的看法，受我个人能力的限制，这些内容很可能是错误的，具体怎么实现的，还是看其他大佬或者AI的分析吧
嗯？是不是有点过度紧张了，仔细想想，CVSS也只给到了9.2的评分啊，只要有万分之一的可能性拿到shell，那这评分就能妥妥地到9以上，那这次事件就更像是狼来了的故事中狼没有真正来的那次了，并不是说漏洞不严重，也不是可以忽略它，而是并不需要那么紧张，对于一些小的站点和服务，完全没有必要为此停机。
那么开始反思当时怎么想的，为什么会越来越急急呢？大概是近几年AI的发展实在太迅速了，有了一种在计算机领域AI无所不能的错觉，相信了传言和其他人说的，AI分析只需要15分钟就有利用工具出现，不出一小时就能扫遍全网IPV4的说法。
鉴于我已经习惯了使用外置大脑思考，能不用自己的脑子思考就不用自己的脑子思考的情况。这里直接放出外置大脑替我进行的一些考虑和反思
这是AI总结的利用这两个漏洞获取shell的必要路径
综合下来，在现在大部分公开部署的项目中，都会有意识地避免版本信息向访客的泄露，很多运维工具还会自动地禁用一些高风险的函数，这更是一个可以被利用来进行拒绝服务攻击的漏洞，拿到shell的条件还是非常苛刻的。
但是又根据最坏假设的原则。这个漏洞被预告为能够实现未授权远程代码执行，且影响版本范围如此之大的时候，又不得不加以重视。在这件事情的处理上，我认为前期过度轻视了漏洞可能带来的影响，但中后期又过度的紧张了，其主要原因还是对相应技术的不了解，对CVSS具体评分依据的不熟悉，以及未能保持和控制的心态，对信息的过度解读，以及就算在刚刚还存在的一些思维上的偏差。
继续帖出外置大脑的思考。
既然都习惯用外置大脑思考，之前做出决定前，一定也问过外置大脑的建议。当时所有的模型都说这事情非常严重，需要立即重视和响应，现在是事后复盘时间
这时候还有问题，为什么官方在提前预告的公告里，只是大致说了是 upload_progress 的问题，而没有给出建议的缓解方案呢？
一个良好的正确的处理过程应该是怎样的？
那么再想一想，之前说的AI很快就能做出漏洞利用工具，这一点是真的吗？
这一项我们暂时保持存疑的态度，毕竟两年前我们都不会觉得未来有一天能许愿式编程，难说未来真的有模型能许个愿就能把攻击工具做出来了呢
看到一些站点甚至公共服务网站停止了服务，那这真的是好选择吗？什么时候才应该停呢？
如果未来再遇到这样的情况，推荐的执行步骤是怎样的
好的，这就是这次想要说的全部内容了。这两天各种东西的漏洞纷纷出现，还望大家保持清醒的思考，准确、理智地判断风险，及时采取必要的措施，不要在狼真的来了的时候毫无准备。
最后，祝大家吃好睡好，身体健康。
