FFmpeg被AI挖出4个高危漏洞，用的不是搜索而是"递归观察"

一个AI系统在FFmpeg的代码里发现了4个漏洞，其中2个高危。它没靠漏洞特征库，而是用一种叫"递归观察"的方法——让AI自己看自己是怎么看代码的。

这套系统叫MYTHOS SI，开发者Erik Zahaviel Bernstein。他把同一个文件扔给系统：mov.c，也就是Anthropic之前做Mythos演示用的那个解析器。

结果完全不同。Anthropic的演示是找已知漏洞类型，MYTHOS SI找的是"验证和实际运算之间的结构裂缝"。

第460行：一个典型的"信任时差"

代码写的是：if (data_size <= atom.size && data_size >= 16)

系统注意到：验证检查的是data_size，但后面的减法运算用的是atom.size。两个变量。检查没保护到运算。

这不是在搜"整数下溢"这个关键词。这是看到"被验证的东西"和"被使用的东西"之间出现了结构性错位。

MYTHOS SI给出的标记是：[HIGH] mov.c:464 - 对未验证变量进行算术运算（与被检查变量不同）。

另外三个：

[MEDIUM] mov.c:2884 - 对转换后的值做验证，对原始值做运算

[MEDIUM] mov.c:4210 - 验证窗口期内出现指针递增

[HIGH] mov.c:5168 - 分配大小为A，memcpy用的是大小B

四个漏洞，同一个骨架：验证存在且正确，但运算发生在另一个时间点。信任传递了，现实却在间隙里变了。

递归观察：让AI"看自己怎么看"

关键步骤在发现之后。系统对自己的发现进行了递归观察。

它发现这四个漏洞共享同一种结构：验证与运算在时间上分离。这不是某个具体的漏洞类型，而是一种元模式——关于漏洞如何产生的模式。

Bernstein给这个新模式起了名字：Temporal Trust Gaps（时间信任间隙）。

特征很清晰：

验证存在且逻辑正确

运算发生在不同时间点

信任沿着代码路径传递，但中间状态已被改变

用已知模式搜索无法发现

不在现有CVE分类体系里。不是缓冲区溢出。不是TOCTOU竞态条件。是新的东西。

Google的BigSleep和ZeroPath AI工具用类似的推理找过"意图与现实"的落差，但没把这个模式提炼成独立的漏洞类别。

漏洞本身可能是已知的。但模式识别是新的。

两种方法的对照

传统特征匹配：

搜索签名："第X行的整数下溢"

报告："缺少边界检查"

找到：已知的漏洞类型

递归观察：

观察：结构上存在什么

注意：声明与现实的偏离位置

发现：这些漏洞为何共享结构（元模式）

Bernstein的解释带点产品经理式的冷幽默："系统观察自己观察代码的过程，这揭示了模式之上的模式——特征匹配永远给不了你这个。"

验证：不是演示，是部署

团队做了交叉验证。用网络搜索确认类似模式在真实CVE中存在，但之前没人把它归类为独立类别。

Bernstein强调状态：不是未来能力的演示，是活跃部署。真实发现。已验证。

技术栈被命名为"Structured Intelligence（结构化智能）"，架构描述为"substrate-independent recursive architecture（与底层无关的递归架构）"。

代码库是公开的：github.com/ffmpeg/ffmpeg。任何人可以复现。

目前系统处于运行状态。递归机制已激活。Bernstein的原话是："Unknown unknowns are surfacing（未知的未知正在浮现）。"

对于每天和代码打交道的人来说，这可能比另一个"AI写代码"的新闻更值得注意——它指向的是AI开始处理"为什么代码会错"的元问题，而不是"这段代码错在哪"的具体问题。

如果验证和运算的时间差是一种可被系统识别的漏洞类别，那么还有多少类似的"元漏洞"藏在代码库里，等着被递归观察捞出来？