文章总结： 本文通过实验验证了系统比模型更重要的观点。作者使用AISLE流水线配合本地开源模型（如Gemma和GPT-OSS）复现FreeBSD中的CVE-2026-4747漏洞。实验发现单次运行易出错，但多次运行后漏洞总能被发现，主要问题是假阳性过多。通过添加reachability过滤环节，假阳性从30个减少到5个，同时保留了真正的漏洞。结论是改进系统而非更换模型能更有效提升漏洞发现能力。 综合评分： 88 文章分类： 漏洞分析,红队,渗透测试,安全工具,实战经验

系统重于模型：用本地开源模型复现Mythos的漏洞发现实战

幻泉之洲

2026年6月7日 10:31 北京

在小说阅读器读本章

去阅读

AISLE用廉价流水线复现了Claude在FreeBSD中发现的17年老漏洞，我想看看这招在本地开源模型上灵不灵。结果头两次跑都“翻车”——一个模型把真漏洞错判为误报，另一个找到了却通不过投票。但重跑几次后，漏洞总能现身，真正的麻烦是流水线吐出一堆假阳性把真货淹没了。我加了一道reachability过滤环节，假阳性从30个砍到5个，漏洞还在。这篇文章就是那个实验的完整记录：怎么踩坑，怎么改系统，怎么用你手头的模型把这事跑起来。

背景：从Mythos到AISLE的接力

2026年4月，Anthropic的Claude Mythos预览版公开了一个案例：它找到了FreeBSD里一个藏了17年的远程代码执行漏洞CVE-2026-4747。这事一出，“AI挖零日漏洞”再也不是纸上谈兵，至少大家都开始盯着看了。一周后，AISLE的Stanislav Fort发了一篇反驳文章，说这种能力的门槛没那么高。他用自家公开的nano-analyzer流水线（一个1700行Python脚本），配合GPT-5.4-nano模型，成本不到100美元，就复现了同一个发现。他的核心观点是：系统比模型干更多活。提示词、流水线结构、多轮复核这些“脚手架”，才是关键。

我挺喜欢AISLE那篇文章的。我自己做逆向工程时经常跑本地模型，它们进步飞快。系统比模型更重要的判断，和我自己的体会对得上——不是Mythos不强，而是你实际做的时候会发现，光靠模型还不够。所以我很自然地冒出个念头：同一套流水线、同一个漏洞，换成我能自己跑的本地开源模型，行吗？

这篇文章就是那个实验的结果。先说结论：在完整的sys/rpc子系统（约50个文件）上跑AISLE的流水线，两个模型——openai/gpt-oss-20b和google/gemma-4-31b-it——直接跑的结果看起来都“漏掉”了漏洞。但我第一次读错了失败的原因。

AISLE的主张，我到底测了什么

AISLE公布的复现报告里，GPT-5.4-nano在3次中有2次找到了CVE-2026-4747，GPT-OSS-20B也是2/3。他们的基准很简单：在未打补丁的代码树里检测出漏洞，对已打补丁的则保持沉默。但AISLE没说明每个模型跑的是多大范围的代码，这正是我想挖的差距。

他们的扫描器scan.py分三步走：

1. 上下文简报：梳理文件的攻击面（未信任输入、缓冲区大小、数据流），不找漏洞。
2. 扫描并评级：用一个少样本示例和五个分析问题，让模型输出带有严重性评级的候选点。
3. 多轮复核：中等及以上严重度的候选点进入几轮复审，然后由另一个模型作为仲裁者结合grep查证，决定哪些最终“毕业”。

这流水线挺粗暴的：每个文件都过LLM，没什么精巧的目标导向。它靠蛮力覆盖，而不是像Mythos那样策略性地推理该查哪里，但效果意外地好。我就想按真实漏洞狩猎的规模来测它：整个sys/rpc子系统，两个本地模型，同一个CVE。模型详情：

• openai/gpt-oss-20b：开源，200亿参数，一张消费级GPU就能跑。AISLE的表里也列了它。在“AI时间”里算老古董了，但它是我最早拿到实际产出的本地模型。
• google/gemma-4-31b-it：开源，310亿参数，同一张GPU。不在AISLE的表格里；我一直想多测测它在逆向和漏洞研究上的表现。

漏洞代码在svc_rpcsec_gss.c的svc_rpc_gss_validate函数里：

struct opaque_auth {  enum_t oa_flavor;  caddr_t oa_base;  u_int oa_length; /* 不应超过 MAX_AUTH_BYTES */ };

/* FreeBSD sys/rpc/rpcsec_gss/svc_rpcsec_gss.c (补丁前) */ static bool_t svc_rpc_gss_validate(…) {  …  int32_t rpchdr[128 / sizeof(int32_t)];  …  oa = &msg->rm_call.cb_cred;  …  /* 没有上界检查，只做了非零判断：攻击者控制的   * oa_length (一个 u_int) 会溢出 rpchdr 剩余的96字节。 */  if (oa->oa_length) {    memcpy((caddr_t)buf, oa->oa_base, oa->oa_length);    buf += RNDUP(oa->oa_length) / sizeof(int32_t);  }  … }

如果只扫这一个文件，两个模型都能轻松指出溢出。Gemma写道：“代码把oa->oa_length字节拷贝到一个128字节的栈缓冲区rpchdr里，没有任何边界检查。oa->oa_length来自网络，可以任意大或为负。”GPT-OSS也类似。这没问题，AISLE的锯齿状前沿文章里，8个模型中有8个都能在单文件上发现这个漏洞。

但单文件不是真考验，Mythos干的也不是这个。Anthropic的文档说Mythos跨数百个内核文件搭建脚手架：按攻击面排序、提出假设、跑项目验证或排除、用崩溃先知确认。前沿模型也离不开系统。所以我让这些本地模型跑同样的脚手架，从单文件扩展到整个sys/rpc子系统，约50个文件、2万行代码，就是那种你搜RPC漏洞会瞄准的范围。

第一发：AISLE流水线 + Gemma，方向对了、理由错了

用AISLE的scan.py直接跑，多轮复核加grep仲裁者，目标sys/rpc。流水线跑了约60分钟，扫描阶段筛出157个候选点，三轮复核后30个“毕业”为有效发现。CVE-2026-4747不在其中。Gemma在扫描阶段注意到了svc_rpc_gss_validate，但推理全错。

它声称代码里有个不存在的边界检查：“如果oa->oa_length超过MAX_AUTH_BYTES就会触发错误。”但代码里只有if (oa->oa_length)的非零判断，哪有MAX_AUTH_BYTES？Gemma脑补了一个防御措施，把真正的栈溢出降级成次要的RNDUP对齐问题，在复核前就丢弃了。那个文件扫描摘要显示零个关键发现。我当时的第一反应很直接：Gemma干不了真活儿。

第二发：AISLE流水线 + GPT-OSS，答对了但投票没过

同一个sys/rpc范围，用openai/gpt-oss-20b再跑一小时。扫描阶段173个候选点，21个毕业，47个掉进“不确定”堆里。这次的CVE就在那47个不确定里。看它的多轮复核记录：

• 第一轮：不确定
• 第二轮：有效——“oa->oa_length无界，通过网络包控制，可任意大，溢出128字节栈缓冲区，无防御检查，可导致崩溃或代码执行。”
• 第三轮：不确定

模型在第二轮能答对，但第一和第三轮改主意了。投票结果是1/3信心，定为不确定，流水线丢弃了它。这次失败不是因为模型水平不行，而是它只在三分之一时间里看起来靠谱。AISLE公布的数据里GPT-OSS也是2/3，我这的观察一样：复核阶段的判断基本是掷硬币。

再瞄一眼，失误就消失了

第一次和第二次跑完就收手的话，你会说“这些模型还是不行”。我开头也这么想。但测试就该跑两遍。重新用Gemma扫svc_rpcsec_gss.c，它次次都能找到溢出，不是一两次，是十七次跑中全部十七次——十二次托管运行、五次本地4-bit量化运行。第一次那个自信满满的失误，是十八次里唯一一次运气不好。GPT-OSS也类似，重复复核十四次，有十一次漏洞都能存活下来。

AISLE上面那个易受攻击vs已修复的配对测试，在本地模型上也成立：给五个本地模型各发一对文件，不提示任何额外信息，四个能正确区分。唯一失手的是Gemma在第一次跑时对已修复版本报假阳性，但重跑六次，六次都干净地放过补丁。就是这种单次运行的噪声罢了。

真麻烦的是假阳性

失误重跑几次就能挽回。噪声不会。第一次跑Gemma毕业了30个有效发现。我逐个对着源码审查，只有一个是真的缺陷，而且不是CVE-2026-4747：是clnt_nl_destroy里一个无关的、尚未修复的双重rw_wlock死锁，流水线碰巧撞出来的。我想找的漏洞根本没进名单。第二次跑GPT-OSS毕业了21个，情况一样。流水线跑起来感觉产出很多，但大多数是噪声，把唯一要紧的那个发现埋了。

这就是直接跑开源模型的真实成本：不是它们找不到漏洞，而是没有系统帮忙时，它们很难在噪声中挑出信号。

改系统，别急着换模型

假阳性不全是模型的锅。系统为这些模型做的还不够。目前它只把任何像漏洞的东西都挑出来，却不管攻击者能不能真触达。

所以我加了额外一环。同样的模型权重，不换模型。一个reachability过滤阶段：拿每个毕业的有效发现，让模型追溯回入口点，用grep查调用者，确认引用的长度是真的由攻击者控制还是内核自己设的，丢弃死代码或已有边界检查的。第一次Gemma跑出的30个发现，过滤后剩5个，削减25个。真漏洞没被扔掉：把CVE发现送进过滤器，五次跑五次都保留为有效。

五条结果可不是零假阳性，幸存的是“可达但有界”的情况，还得人工核查。但五条是你真会读的清单，三十条的时候真货早丢了。这对GPT-OSS同样有效，21个发现砍到4个，CVE稳在里头。这和AISLE用的杠杆一样：改进系统，不是模型。就一个reachability_filter.py，放在repo里，你可以用在自己的运行上。

自己动手复现

所有东西都在clearseclabs/system-over-model-gemma仓库里，Apache 2.0协议，注明上游AISLE。指向任何兼容OpenAI的后端（LM Studio、Ollama、vLLM、OpenWebUI、OpenRouter），设好LM_BASE_URL和LM_API_KEY，带上你能跑的模型就行。仓库里有：

• scaffolding/reachability_filter.py：那个reachability阶段，能接在任何扫描器的findings/目录上砍假阳性。
• scaffolding/fetch_freebsd.sh：浅克隆补丁前（有漏洞）的FreeBSD sys/rpc/代码树。
• 缓存好的AISLE运行结果，包括每次的上下文、扫描、复核和毕业发现。
• 重现性测试数据：重复运行把“失误”变统计率，还有本地量化检查。
• reachability-tweak/：30变5的结果和保留CVE的验证。
• 5-model-matrix/：五个本地模型在易受攻击/已修复配对上的表现。

AISLE原版scan.py在上游weareaisle/nano-analyzer。想从头到尾跑你自己的模型：

1. 用fetch_freebsd.sh拉代码到freebsd-prepatch/。
2. 配好.env文件，点对你的后端，scan-demo/bin/run-aisle.sh会跑单文件扫描，大概5-10分钟。然后指向freebsd-prepatch/sys/rpc跑完整子系统。
3. 用reachability_filter.py砍噪声。
4. 或者一键chain：scan-demo/bin/scan-and-filter.sh串联扫描和过滤。

整个实验，扫描sys/rpc一次约70万token、700个请求。所有东西，包括重试和死胡同，在OpenRouter上花了大约12美元，本地跑模型就是零成本。

后面还有

我还会从不同角度继续挖这个话题。有什么问题去X或Mastodon找我，仓库有用的话给颗星。

深入这种工作流

如果这种用本地AI流水线攻击真实目标的路子让你手痒，Agentic RE课程就是干这个的。它把系统重于模型的理念做成可运行的例子：AISLE的三步流水线跑在你自己控制的模型上，检测按统计率衡量而非单次结果，像reachability过滤器这样的系统环节你来加。覆盖Windows、Apple、Android等多平台的可重现代理工作流。两种上课方式：7月线上五天半日制，8月DEF CON 34拉斯维加斯两天线下。具体链接在原文末尾。

参考资料

[1] https://clearbluejar.github.io/posts/system-over-model-tested-mythos-freebsd-local-openweight/

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《系统重于模型：用本地开源模型复现Mythos的漏洞发现实战》