本来昨天就想写一个分析的，不过考虑到可能被攻击者利用，就等到Patch出来以后，今天再发吧，本文以已经公开的攻击脚本POC为例，来解释，具体链接我就不放了。

我第一次看到这个漏洞的报告的时候，我就心想，这能是人干的事？也幸亏是AI，超强的综合能力，才能发现这个漏洞，并且利用。上午我还跟同同事说，AI一旦开始研究攻击，那就不仅仅是PHP了，所有的系统都可能会被攻破，毕竟之前的代码都是人写的，而人，一定会犯错。果然，下午的时候，消息就出来了NodeJS也核爆了。

为什么说这个漏洞隐藏的深呢，因为这个漏洞的利用，综合了多个条件，并且需要对PHP的实现有较深的理解, 包括内存管理，Session的实现，反序列化的机制，OOM的处理机制。而要利用这个漏洞就需要更加丰富的系统知识，所以在AI之前，能综合具备这些知识的人，还是比较少的，而就算有这样的知识，也可能没有这样的精力。但，AI来了..

本次我核心介绍危害最大的CVE-2026-109619，它能实现RCE，不过它和CVE-2026-109618共享一个前提，所以讲清楚一个，另外一个也就清楚了。

大部分场景下，PHP都是用的多进程模式，早些年Apache流行的时候，是mod_php, php提供了一个模块，编译进Apache。后来Nginx流行了以后是php-fpm, PHP自己是一个多进程服务，通过sockets接受Nginx的请求转交。

这个模式下，一个PHP进程会常驻，然后来一个请求，处理一个请求。为了保证请求之间不互相影响，PHP会在请求到来之前执行Request INIT(RINIT)，结束之后执行Request Shutdown(RSHUTDOWN)。

PHP的内存是由PHP自己的内存管理器Zend MM管理的，每次请求结束后会重置这个状态。

我们以PHP8.5为例(main/main.c):

/* php_request_startup() */

一般情况下这个工作机制是没有任何问题的，但是永远都有二般：

在出现致命的情况下，比如内存OOM，比如代码BUG导致内存写花，PHP会调用zend_bailout() ，而这个函数内部调用了C的longjmp，跳过了所有的清理代码，这样做也是对的，毕竟如果内存花了，那中间状态都是不可信的，如果做清理，那就可能会读到花的数据，导致不可预期的结果。

而CVE-2026-109618就是利用这一点。

在一般的情况下呢，zend_bailout之后，虽然留了一堆烂摊子，但是在下一个请求来临的时候，PHP的RINIT机制会恢复现场，初始化好所有的环境，所以不会有问题，但还是一样，永远都有二般，真还有那么一个时机，是在PHP RINIT之前被执行的，那就是:

php_hash_environment()

这里面会去构建PHP的超级变量，此时各个扩展的RINIT还没有被调用，而我们此次漏洞的关键的扩展，ext/session，就要提一提了。

Session的RINIT(php_rinit_session_globals)中会初始化一些Session扩展使用的全局变量，但是在Session RINIT还没调用的时候，它还保留者上一个请求遗留的值。

你可能会问，RINIT还没调用，Session怎么会跑到php_hash_environment()里去？

答案是PHP的一个"贴心"功能：Session Upload Progress（session.upload_progress）。这个功能自PHP 5.4引入，默认开启，用途是让前端能在文件上传时显示进度条。它的实现思路是：在PHP解析multipart上传数据的过程中，实时把进度信息写进session文件。

注意这个设计的必须之处：写进度条这种事，等脚本跑起来再写就晚了（上传那个时候就结束了），所以它必须在解析body的时候就写。于是PHP把一个回调挂在了multipart解析器上——第一个带文件的part出现时，这个回调会提前把session初始化了：读取PHPSESSID、

打开session文件、把$_SESSION挂到符号表。而这一切，都发生在RINIT之前。

' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

现在把拼图凑齐。想象同一个PHP worker进程上的两个请求：

请求A（投毒）：

攻击者发一个精心构造的multipart上传。文件part出现，upload progress回调提前初始化了session——此时Session扩展的全局变量里，PS(id)指向了一个请求堆上的zend_string，PS(http_session_vars)指向了一个请求堆上的$_SESSION数组。注意，这些指针指向的内存，是属于请求A的。

紧接着，攻击者让请求A在解析中途OOM了（怎么做到的后面说）。zend_bailout()一跳，跳过了multipart的END回调——本来那里会做session的清理；又因为此刻`PG(modules_activated)`还是0，请求关闭流程里的Session RSHUTDOWN也被整段跳过。但是shutdown_memory_manager()是无条件执行的——请求A的堆，连同里面那个session id字符串和$_SESSION数组，整个被释放了。

注意此时，PHP worker本身并没有死，但它的全局状态里留下了两个悬空指针：指针还在，指着的那块内存已经还给了Zend MM，等着被下一次分配领走。

请求B（引爆）：

攻击者再发一个multipart请求。这个请求不带文件，只带两个普通的表单字段：

PHPSESSID=攻击者选定的id

和

PHP_SESSION_UPLOAD_PROGRESS=任意值。

因为没有文件part，upload progress的初始化路径不会触发，请求B会直接走到multipart的END回调。而END回调里有一个清理函数，它会调用php_session_initialize()——于是PHP顺着那个从未被重置的悬空指针，去读一块已经被释放、并且刚刚被请求B自己的数据重新占据的内存。

这里有个关键认知：请求B的字段名和字段值，每一个都会让PHP emalloc一次，分配的大小由字段长度决定。而PHP为了内存分配的效率，有一个机制是同样大小的内存，基本上会在一个小的list里分配，所以攻击者可以精确设计这些长度，让请求B的某次分配，恰好领回>请求A留下的那块悬空内存。领回来之后，这块内存里装的是什么？是攻击者在multipart里填的字节。

也就是说，PHP拿着"这是一个合法的session结构"的旧记忆，去解读一块内容完全由攻击者控制的内存。这就是经典的UAF(use-after-free)。

那怎么把一个UAF变成RCE？

公开的PoC中给出了完整的答案，整个攻击分四个阶段，全程纯HTTP：

第一步，把OOM变成可控的打断原语。要触发上面说的机制，攻击者得能在session已初始化、清理还没执行的窗口里制造fatal。三个放大器让这件事在默认配置下轻松做到：没有Content-Length的chunked multipart可以绕过post_max_size的预检查；单个part可以塞无限多的header，内存里的表示比线上体积大得多；filename=""的空文件控件不计入max_file_uploads，但六个$_FILES元数据数组照建。于是几MB的请求体，能打爆128MB的memory_limit——OOM发生在攻击者选定的精确位置。

第二步，泄露。悬空的PS(id)被引向一块被回收重填的内存，攻击者在那里伪造了一个zend_string的长度字段。PHP生成Set-Cookie头的时候，把这个"长度"的字节原样吐了出来——响应头里带了4KB的堆内容。攻击端扫一遍，就拿到了堆基址；换个姿势再泄一次，这次泄露的是某个HashTable里的pDestructor字段——那是一个指向libphp代码段的函数指针。ASLR在这一刻宣告失效：已知的函数偏移减去泄露的指针，就是libphp的加载基址。

第三步，伪造。攻击者在multipart字段里写一个精心布局的167字节结构：一个伪造的HashTable（析构函数指针pDestructor被写成了zif_system的地址）、一个伪造的execute_data（参数个数为1）、一个伪造的zend_string（内容是待执行的命令）。再让一次分配把这个结构恰好搬到悬空指针指向的地址上，把PS(http_session_vars)指向的位置覆盖成一个假的引用，指向这个伪造的HashTable。

第四步，引爆。请求B走到END回调，PHP的清理代码顺着悬空指针开始析构它以为的session数据：zval_ptr_dtor → zend_reference_destroy → zend_array_destroy → zend_hash_destroy——最后这一步，HashTable的析构会为每个元素调用pDestructor。而这个pDestructor，是攻击者写的zif_system。命令执行了，输出重定向到web目录，攻击者再发一个普通的GET请求把结果取回来。

整个过程HTTP返回200，worker不崩，应用日志里干干净净。目标的PHP页面哪怕只有一行

<?php echo "OK"; ?>

也照打不误——因为从始至终，攻击发生在应用代码开始执行之前。

' fill='%23FFFFFF'%3E%3Crect x='249' y='126' width='1' height='1'%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

还有一个更"优雅"的变体值得说一句：甚至不需要内存破坏。攻击者想办法把恶意的序列化对象写进session文件,比如：

O:3:"CMD":1:{s:3:"cmd";s:2:"id";}

upload progress在RINIT前读session时会把它反序列化成真实对象，对象的__destruct()被PHP"合法地"调用——如果目标应用里恰好存在一串魔术方法能接力到system()的gadget类（WordPress、Laravel这类生态里从来不缺），RCE就成了。这条路完全不需要碰内存布局，稳定得可怕。

现在你也能理解为什么这个漏洞难防了：

它不需要认证——攻击请求就是普通的HTTP POST；

它早于应用代码——路由、中间件、WAF规则、ini_set()统统来不及跑；它的入口默认开启——upload_progress从PHP 5.4起就是On，不需要应用调用session_start()；session.use_only_cookies=1也挡不住，因为攻击者可以把PHPSESSID放在表单字段里。

最后回到AI这个话题

这个漏洞最让我感慨的，不是漏洞本身——写PHP内核这么多年，"请求边界上的状态清理"这种坑，我知道它一直有风险——而是发现它的方式。发现它的安全研究者自己说：没有用什么特殊harness，没有私有模型，就是研究者带着二十年的PHP漏洞史认知（Stefan Esser在2004年就发现过第一代memory limit漏洞），明确地引导AI去做变体分析。AI像是一个不知疲倦、读过所有历史漏洞的审计员，把"publish state → fallible work → commit"这个模式在百万行代码里扫了一遍又一遍，而人负责提出正确的问题。

所以"AI会不会取代安全研究员"这个问题问错了。AI发现不了你不知道该问什么的问题，但它能把你知道该问的问题，问到人力永远达不到的深度和广度。知识在人的脑子里沉淀成方向感，AI把方向感展开成地毯式搜索。

这次是PHP，下午是NodeJS。底层的C库、Python的解释器、JVM……所有"人写的、跑了几十年的"代码，都在同一架显微镜下面了。基础设施软件没有"安全默认"，只有"默认暴露"——这句话送给所有还在跑PHP 7.x的同学。

升级吧，今天。

当然，也有一个办法就关闭PHP的上传进度反馈，这个从根本上可以杜绝RCE，但是不能解决OOM可能带来的DDOS攻击:

session.upload_progress.enabled=Off

记得这个需要设置在php.ini中，不能通过ini_set，原因你也懂。

当然，聪明的你想，既然要跨请求才会出现，那就还有一个极端的办法，就是让每个Worker只处理一个请求，fpm设置:

pm.max_requests = 1

Apache设置:

MaxRequestsPerChild 1

但，这个方法过于凶残，属于宁为玉碎，不为瓦全，各位自行斟酌吧.

本文转自 https://mp.weixin.qq.com/s/bB2EqImUlslJGCs7melQGw?poc_token=HMe_2mqjRyyGbIW5DOBSGT2-zqSyUAWjLK6btqCQ，如有侵权，请联系删除。

丸子中转

点击联系我 (2064320087)

我在codex里面告诉它：编写一个golang 协程案例到当前docs下

codex 啪啪啪的拿到大模型内容然后建立目录和文件，那这个过程是怎样的呢？我们假设有个简易版的codex，你问它，它只会回复而不会建立目录和文件。如此对比，我们来分析：

现在我们的 proxy 只打通了“模型文本输出”，没有打通 Codex 的“工具调用协议”。

你在 简易版Codex 里说：

编写一个 golang 协程案例到当前 docs 下

正常 Codex 要写文件，流程不是“模型自己写磁盘”。真实流程是：

Codex 客户端
-> 调模型
-> 模型返回 tool call，例如 apply_patch / shell command
-> Codex 客户端执行工具
-> 文件才真的落盘

但我们现在的链路是：

简易版 Codex
-> /v1/responses 或 /v1/chat/completions
-> 返回纯文本 delta
-> Codex 收到普通 assistant 文本

这里缺了关键一层：

模型返回 Codex 可识别的 tool_call

所以 Codex 最多会拿到类似：
可以在 docs 下创建一个 go_concurrency.md，内容如下...

但它不会真的动文件，因为它没有收到标准的工具调用事件。

解决什么问题？

当你的视频素材库积累到成千上万小时，找东西就变成了一场灾难。

• 剪辑师："上周拍的那个夕阳海边的镜头，在哪个硬盘？"
• 零售运营："想看看所有试穿黄色外套的顾客片段"
• 安保人员："监控里那个穿黑夹克的男的，前后半小时的活动轨迹"

传统的关键词搜索帮不上忙，因为它只认字，不认内容。我们做了一个能"看懂"视频的搜索系统，让你用日常语言就能找到想要的片段。

场景一：媒体与娱乐行业

谁在用： 电视台、视频制作公司、短视频平台的剪辑团队

遇到的问题：

• 素材库越来越大，找素材靠记忆和运气
• 一个专题片要翻阅几十小时的原始素材
• 跨部门协作时，沟通成本高（"那个蓝色背景的镜头是哪一卷？"）

怎么用：

• 语音搜索：「找一段夕阳下海边的奔跑镜头」
• 属性组合：「红色连衣裙 + 侧脸 + 微笑」
• 场景描述：「室内 + 两个人在对话 + 桌上有咖啡」

实际效果：
原来需要 2 小时翻找素材，现在 30 秒搞定。剪辑师可以专注于创作本身，而不是在硬盘里大海捞针。

场景二：智慧零售

谁在用： 连锁零售店、商场、品牌方

能做什么：

1. 顾客行为分析

• 「所有试穿黄色外套的顾客」
• 「在某个货架前停留超过 30 秒的人」
• 「推着购物车但没有买任何东西就离开的」

2. 运营效果监控

• 「收银台排队超过 5 人的时间段」
• 「促销活动期间的人流变化」
• 「某个商品被拿起的次数统计」

3. 服务质量检查

• 「员工与顾客互动的场景」
• 「空柜台的时段分布」

价值：
不用再看监控录像"人工统计"，想查什么说一句话就能找到。可以快速发现运营问题，优化门店布局和人员配置。

场景三：司法取证

谁在用： 公安技侦、律师事务所、保险公司理赔部门

典型需求：

1. 快速定位

从几十小时的监控录像中，找到：

• 「穿黑色夹克男性的活动路径」
• 「某个时间点之后所有进入该区域的人」
• 「与目标人物有过接触的人」

2. 证据链整理

自动生成时间线：

• 什么时候出现在哪里
• 和谁有过互动
• 做了什么动作
• 关键帧截图和文字说明

3. 保险理赔

• 「事故现场的受伤人员行动轨迹」
• 「某车辆在某个时间段的所有出现记录」

价值：
原来需要 3 个人看 1 天监控才能找完，现在 10 分钟出结果。而且系统不会漏掉细节，不会疲劳。

技术原理（简说）

传统搜索为什么不行？

关键词搜索只匹配文字标签。但视频内容是连续的、丰富的，很难提前打全标签。

• 搜索"女人" → 找得到"女人"两个字
• 但找不到"穿灰色内衣的女人"（因为标签里没有"内衣"）
• 甚至会误匹配到"穿灰色上衣的男人"（关键词碰上了）

我们的方法

第一步：让系统"看懂"视频

• 视频分段后，用视觉模型理解每帧内容
• 生成结构化描述：人物、动作、场景、服装、物品...

第二步：用文字搜索

• 你的查询"灰色内衣的女人"会被拆解成多个条件
• 每个条件独立评分，取最小值作为整体匹配度

第三步：智能过滤

• 用语言模型对搜索结果进行二次判断
• 识别语义不匹配的内容并过滤掉
• 比如：查询"女人"，但结果里是"男人"，直接剔除

实际效果对比

查询：「灰色内衣的女人」

部署方式

本地部署

• 数据不出内网，安全可控
• 支持离线环境，无需外网连接
• 可部署在普通服务器上（GPU 可选，有则更快）

联系我们

如果您的业务也有海量视频检索需求，欢迎联系我们获取定制化方案。

我们提供：

• 现场演示和试用
• 根据您的具体场景优化搜索效果
• 与现有系统集成的技术支持
• 培训和技术服务