标题卡上写着“133 个代理,一个 Django CVE”,位于“Mistral Large 4 · Le Chonk”标签上方,并带有“133 个代理”“90x 播放”和“0 个已命名 CVE”标签,一个包含 133 个点、其中一个代理被高亮的网格,以及页脚注明 Django 于 11 月 3 日发布了六个 CVE 修复:一个中危、五个低危、没有严重级别。
Engineering & Research

Mistral Large 4 的 133 智能体 Django 演示:它复现了一个 Django 早已修复的 Bug

作者

Rowan Sterling

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

Mistral Large 4 是 Mistral AI 绰号为 Le Chonk 的 1.05 万亿参数开放权重模型,于 2026 年 11 月 4 日作为一个端到端安全研究员被展示。Mistral 官方 X 账号的一篇帖子询问该模型能否“发现一个严重漏洞、证明它并修复它”,随后用 133 个智能体、一个 Django 代码库和一段 90 倍速延时视频作为回答。该帖子没有点名任何 CVE。它没有发布补丁。它没有给出运行时间、token 数量、误报数量,也没有提供技术文章的链接。

时机缩小了范围。Django 安全团队在前一天,即 2026 年 11 月 3 日,已在 6.1.3、6.0.10 和 5.2.19 中发布了针对六个 CVE 的修复(其中一个问题未列出 5.2 补丁)。如果那一批就是目标——而且它是那一周新闻中唯一一批 Django CVE——那么该演示不可能发现了一个未知漏洞,因为所有六个漏洞在视频发布前都已公开并修补。它也不是一个严重漏洞。其中一个被评为中等风险;其余五个被评为低风险。

这并不会让该演示变得毫无价值。它使其成为一次工作流演示,而非一项发现主张;而对于任何正在决定开放权重模型能否在安全团队的分诊队列中占有一席之地的人来说,这一区别很重要。

Mistral 实际展示了什么

这篇帖子很短:“Mistral Large 4 能找出一个严重漏洞、证明它并修复它吗?我们在最近的一个 Django CVE 上测试了它。133 个智能体梳理代码、搜寻缺陷、测试攻击场景并确认该漏洞。然后由 Le Chonk 修补。初筛、复现、修补。以 90 倍速展示。” 截至撰写本文时,它获得了 540 个赞、94 次转发、107 条回复和约 21,000 次浏览——这是一篇颇有分量的产品帖,而非一次漏洞披露。

Mistral 自己的发布说明更详细地描述了同一套工作流程。开放权重公告中列出了一个“Cyber Vulnerability Triage”智能体,它会读取收到的漏洞报告,在隔离沙箱中复现这些缺陷,编写并迭代补丁,并持续进行,“直到金丝雀漏洞利用不再有效”。这是该模型的一项有文档记录的功能,早在视频之前就已写下。133 个智能体的运行是对它的公开演示。

90× 这个数字是播放速度,而不是结果。如果没有源视频的时长或这次运行的挂钟时间,就无法把它换算成一段持续时间。两小时运行的 90× 延时摄影和两天运行的 90× 延时摄影,在时间轴上看起来一模一样。

Django 批次,以及为什么“critical”并不贴切

Django 11月3日的安全公告异常具体,这正是它作为对照很有用的原因。公告列出了六个问题,每个问题都包含 CVE、报告者、受影响分支集合和修复提交。这些问题的严重程度都远未达到严重级别:

• CVE-2026-111362 — 中危。GeoJSON 几何体的 crs 成员可能导致 GDAL 在校验、保存或查询期间发起网络请求或读取本地文件:这是一条 SSRF 与本地文件读取路径。

• CVE-2026-108147 — 低危。Base64 编码的分段上传在上传处理程序运行之前就被缓冲,绕过了 FILE_UPLOAD_MAX_MEMORY_SIZE,可能导致内存耗尽。

• CVE-2026-111211 — 低危。无效几何表单值中的控制字符被记录时未进行转义,可能导致日志注入或日志伪造。

• CVE-2026-113593 — 低危。缺失和空的 Vary 头值会生成相同的缓存键,存在暴露私有缓存响应的风险。

• CVE-2026-113733 — 低危。仅具有查看权限的管理员用户可以看到某些自定义用户模型的完整密码哈希。

• CVE-2026-114582 — 低危。SpatialReference 字符串输入可能触发 GDAL 的 URL 获取或文件读取;完整防护需要 GDAL 3.9 或更高版本。

全部六个问题都在同一天被修复。这就是 Django 的正常流程:安全公告、补丁和 CVE 记录会一同落地。一个在一天后才“确认这个 bug”的模型,确认的是一个修复已经进入代码仓库、且复现步骤已经出现在公开报告中的 bug。复现一个已报告的 bug 是分诊队列的首要工作,所以这确实是实打实的工作——但这与发现一个 bug 并不是一回事。

Mistral 没有指明该 CVE 的编号,因此无法对照具体的安全公告来核实这一说法。如果目标不在 11 月那批范围内,该帖没有提供任何方法来识别它、确定其日期,或将生成的补丁与上游修复进行比较。补丁本身并未公开。

Screenshot of the Django 3 November 2026 security release page showing the 6.1.3, 6.0.10 and 5.2.19 releases, CVE-2026-108147 and CVE-2026-111211 labelled low severity, and CVE-2026-111362 labelled moderate.

133 个智能体是一个编排数量

智能体数量是一种设计选择,而不是一个评分。一条流水线可以使用 133 个智能体,因为它会按每个文件、每个假设或每条攻击路径进行扇出;同样的工作也可以用五个智能体和更多轮次来完成。随数量变化的是成本、延迟和独立尝试的次数——而不是模型按 token 计的能力。

让这个数字有意义的指标恰恰是缺失的那些:提出了多少候选缺陷,有多少是误报,每确认一个缺陷需要多少个智能体,以及这次运行消耗了多少 token。一个提出 200 个候选缺陷才确认一个真实缺陷的系统,与一个只提出三个候选缺陷并确认一个的系统,是不同的产品,而两者都可以诚实地被描述为“133 个智能体”。

Mistral 公布的描述所指向的是一个范围有限、可验证的闭环,而非开放式的探索:在沙箱中复现,围绕补丁反复迭代,一旦金丝雀漏洞利用失效便停止。这个闭环正是 Django 演示所展示的内容。这是一个不错的闭环。它同时也是人工分诊员借助调试器和测试套件所运行的闭环。

Mistral 确实公布的安全数据

Mistral 的开放权重博文称,Mistral Large 4 在 Artificial Analysis Cyber Index 上的得分为 51%;在这张由厂商自行制作的图表中,MiMo-V2.6-Pro 为 56%,DeepSeek-V4.1-Flash 1017 为 57%,Kimi K3 为 41%,GLM-5.3 为 36%。该指数考察的是模型能否在代码库中发现漏洞、复现并验证漏洞以及修补漏洞——这正是演示中那三个动词。

同一篇帖子报告称,对恶意网络请求的平均拒绝率为96.6%,Mistral称这是其在开放模型中测得的最高值;在B3智能体安全基准上的抗攻击率为97.1%,高于预览版的93.3%。10月的预览页面还列出了Mistral自有漏洞复现与修补测试中82%的得分,以及在40项Cybench挑战中93%的通过率;开放权重帖子没有重复这两个数字。

所有这些都来自厂商自报。没有任何一项经过独立复现,而且 Cyber Index 图表是 Mistral 对第三方指数的呈现,而非排行榜截图。这并不意味着这些数字是错的。它只是使它们成为主张,而演示视频则是同一系列中的又一项主张。

这种定位存在真实的张力。一个被调校为拒绝 96.6% 恶意网络请求的模型,同时也在以其复现漏洞利用和编写补丁的能力作为卖点。Mistral 的答案是面向渗透测试和红队演练的专门变体,须通过审查并受合同限制,仅限用于自有或获授权的系统。开放权重检查点是通用模型,其护栏可由托管方调校——这正是为什么两用问题随权重而来,而不是随 API 而来。

Screenshot of the Mistral Large 4 model card on Hugging Face showing the Le Chonk title, 1 trillion total and 49 billion active parameters, a 1M-token context, text-and-image input, the NVFP4 checkpoint note and evaluation results including Terminal-Bench at 41.

什么能把演示变成证据

一个可信的端到端主张需要具备六样东西。这些没有一样是离奇的;而它们全都在这篇帖子中缺席。

• 一个具名 CVE,或一个没有公开报告的漏洞——以便读者能区分发现与复现。

• 存在漏洞的提交和已修补的提交,以便可以审查差异。

• 在同一环境中进行前后对比复现,包括失败的漏洞利用和成功的漏洞利用。

• 假阳性数量:在有一个候选存活下来之前,代理们提出了多少候选。

• 完整运行的实际耗时和 token 成本,而不是回放倍率。

• 由非 Mistral 的第三方独立重新运行。

公布那些内容,论证就会改变。在那之前,诚实的描述是“Mistral 在一个公开的 Django 缺陷上演示了其分诊代理”,这是一次有用的产品演示,而且比文章第一句话所主张的范围要小得多。

Generated card titled 'What the post claims vs what it proves', with six rows contrasting claims such as finding a vulnerability and critical severity against the published evidence, and a verdict strip reading 'a workflow demo, not evidence of discovery'.

在你自己的代码库上运行该模式

开放权重对安全团队而言才是关键所在。Mistral 于 2026 年 10 月 29 日根据 Mistral Ecosystem Open-Weight License 发布了该检查点;这是一份修改版 MIT 许可证,允许使用、修改、微调和商业化,但任何经营模型即服务业务的人都必须获得单独许可证。该检查点拥有 1.05 万亿参数,每个 token 激活 490 亿参数,上下文长度为 100 万 token,并面向 Blackwell GPU 提供 NVFP4 变体。自托管它意味着一笔集群采购,而不是在笔记本电脑上下载,但它能将源代码和发现保留在你的边界内——这正是安全团队会选择它而不是 API 的原因。

这套工作流程比模型更具可移植性:梳理代码、生成候选缺陷、模拟攻击、在沙箱中复现、打补丁,然后验证该漏洞利用不再触发。每个实现中的薄弱环节都是验证器。写补丁的同一个模型并不擅长评判它;来自不同模型家族的第二个模型,在拿到差异和复现结果后,能捕获相当一部分第一个模型会为之辩护的糟糕补丁。

这正是路由发挥作用的地方。Mistral Large 4 不在 OrcaRouter 的目录中——它由 Mistral 自己的 API 提供服务,并可下载用于自托管——但 OrcaRouter 能让 200 多个其他模型通过一个兼容 OpenAI 的密钥访问,按提供商标价 0% 加价,具备自动故障转移,并借助可将第二意见验证器组合进同一次调用的路由 DSL。分诊流水线不需要一个模型样样精通;它需要补丁编写者和补丁审查者由不同模型担任,而用一个密钥比签两份供应商合同更便宜地实现这一点。

值得关注的声明

Mistral 具备构成可信安全产品的各个部分:开放权重、有文档记录的分诊闭环、较强的拒答指标,以及一个衡量正确动词的基准。它在公开层面缺少的,是一个模型发现了尚未修复问题的案例。下一次演示应当点名漏洞、发布 diff,并让别人来运行它。在此之前,133 个智能体的视频只是编排能力的演示,而非发现能力的证据——而“critical”一词所承载的分量,已经超出了 Django 批次所能支持的范围。