最近一段时间，AI 在安全圈的动作越来越不像"玩具"。
7 月 23 日，Linux 内核主线合入了一份只有 6 行的补丁，修复的是一个在代码里潜伏了 18 年的 0day 漏洞——编号 CVE-2026-64564，被发现者命名为 SCTPhantom。能在主干代码里"躲"这么久，本身就是一件值得说道的事：因为同一份代码，过去 18 年里被 Google 的 syzkaller 顶级 fuzzer 反复测试过，被全球数千名开发者审阅过，也被无数安全研究员手工审计过。
发现它的不是人，也不是一个 fuzzer，而是腾讯 TencentOS 安全团队自研的内核漏洞研究智能体——"科维斯 AI"（Corvus AI）。从 KASAN 级别的崩溃复现，到在真实内核中拿到稳定 root 权限，再到把这条利用链迁移到 Debian 默认内核只花 3 小时，整个过程都在科维斯 AI 自己的驱动下完成。
这件事的意义，比"又一个 0day"大得多。它意味着：内核漏洞的发现、验证、修复，可能第一次站在了一个能规模化复用的工程化入口上。
SCTPhantom 位于 Linux 内核的 SCTP 协议栈。SCTP 是一种主要用在电信、专网通信和部分基础设施里的传输协议，跟我们日常上网接触最多的 TCP 不太一样：一条 SCTP 连接可以同时绑定多个网络地址，也允许在连接存续期间动态新增、删除地址。这种"灵活"，正好为漏洞提供了藏身之处。
问题出在"地址删除"那条路径上。单独看每一个操作，都符合协议规范；但当三个特定参数按照特定顺序出现在同一条消息里时，前一个操作已经释放的内核对象，会被后一个操作继续使用——这就是典型的 Use-After-Free。
为什么它能藏 18 年？TencentOS 团队的复盘给了一个非常清晰的解释：这类问题不是单看一个函数就能发现的，研究者必须同时理解协议状态、参数执行顺序，以及同一个内核对象跨越多个处理阶段的生命周期。换句话说，它藏在一个"组合条件"的角落里，每一次局部审查都没把它单独暴露出来。
相关代码是在 2008 年进入 Linux 上游的，跟着 v2.6.25 一起发布。18 年里，内核版本号从 2.6 一路走到了 6.x，模块组织、调度器、文件系统换了不知道多少代，但 SCTP 地址删除这条路径始终没有被人真正盯死过。
用他们自己的比喻是：坏人原本只有一张普通访客卡，利用这个漏洞后，却可能拿到整栋楼的总钥匙。（来源：腾讯技术工程官方公众号，2026-08-06）
二、从一次 crash 到稳定 root，中间发生了什么
发现一个能导致崩溃的内存错误，在内核安全研究里只是起点。
科维斯 AI 围绕 SCTPhantom 自主写了第一版 PoC，第一轮就触发了系统崩溃——这只能证明"问题能发生"，并不能证明它"能被用"。真正的工作，是从这次 crash 之后才开始的：
第一，它要回答"攻击者能不能控制被释放后又被使用的内核对象"。这是判断一个 UAF 是否真正可利用的关键，绕不开对堆布局、slab 行为、对象生命周期的细致建模。
第二，它要回答"在真实防护配置下能不能稳定利用"。KASAN 开了不等于线上开了，关闭各种调试选项、打开 SMAP/SMEP/KASLR 之后，这条链还能不能稳定走到 root，是另一道坎。
第三，它要把这条利用链真的跑成 root。TencentOS 团队的描述是"经过多轮实验和复核，最终将一次内核 crash 推进为稳定本地提权"——也就是说，中间是反复"调—跑—判—再调"的循环，研究员和 AI 在这个循环里各自承担判断和动作。
把这三件事串起来的，是他们自研的 Agent Harness 框架。它干的不是"让 AI 更聪明"，而是让"长链路"这件事变得可管理：每一次实验的状态、每一次失败的根因、每一次调整的方向，都会被沉淀下来，供后续 Agent 继续使用。换句话说，它解决的是"研究连续性"，而不只是"研究能力"。（来源：腾讯技术工程官方公众号，2026-08-06）
三、3 小时，把利用链搬到另一套内核
一个漏洞只在某一台机器上能跑通，并不能说明它在真实世界里有多大危害。
TencentOS 团队随即让科维斯 AI 把已经在 TencentOS 上跑通的利用代码，迁移到 Debian 默认内核上重新跑。这件事听起来简单，做过的人都知道——不同发行版用的内核版本、编译选项、内存布局、防护配置都不一样，过去把一套内核利用迁到另一套发行版，往往需要研究员逐项调试，单是定位 29 处偏移就能耗掉一个人一周。
科维斯 AI 的做法是：自动分析两个内核环境之间的差异，重新定位并调整这 29 处内核偏移和符号，再根据编译与运行结果持续修正代码。从接到 TencentOS 上的 EXP，到在 Debian 默认配置里再拿到一次 root 权限，整个过程耗时 3 小时。
这一步完成的不只是"换个发行版再拿一次 root"。它实际回答的是：漏洞在不同产品里的真实危害到底有多广。 这才是操作系统厂商和客户最关心的东西，也是为什么安全研究不能停在 PoC 阶段。
截至披露前，TencentOS 团队已经在以下环境中完成了真实提权验证：
- • TencentOS Server，默认配置可本地提权
- • Debian 13，默认配置可本地提权
- • Ubuntu 24.04，默认配置可本地提权
- • RHEL 9.8 / Rocky Linux 9.8，需预先加载 SCTP 模块可本地提权
- • Docker 环境下，可进一步完成容器逃逸、拿到宿主机 root 权限
需要强调的是，这些只是"已验证"，不等于"影响范围仅限于此"——具体还要看每个发行版的内核代码、补丁状态和 SCTP 配置。（来源：腾讯技术工程官方公众号，2026-08-06）
四、为什么这次不是"又一个 AI 写代码案例"
过去 2 年里，关于 AI 发现漏洞的报道并不少，但多数集中在"给定漏洞描述，AI 写 PoC"的范畴。比如 CyberGym 这类公开 benchmark，主要评测的也是在已知条件下完成 PoC 编写，目标是用户态程序，操作系统内核层面的复杂问题涉及得很少。
SCTPhantom 这件事的特殊性在于：科维斯 AI 是"从零出发"——没有漏洞描述，没有触发样例，也没有标准答案。它要在一个数千亿行规模、覆盖网络、文件系统、虚拟化、驱动、权限管理多个高复杂度子系统的内核代码库里，自己提出漏洞假设、自己跑验证、自己分析失败、自己调整方向，直到形成完整的证据链。
同期，科维斯 AI 还在 Linux 内核的 Open vSwitch 模块里独立发现了另一项本地提权漏洞——编号 CVE-2026-64531，命名 OVSwrap，并完成了稳定 root 验证。两个漏洞分别来自不同的内核子系统，形成机制完全不同，最后都被从零推到可稳定利用——这一点的可信度，远高于"AI 跑了一个 benchmark"。（来源：腾讯技术工程官方公众号，2026-08-06）
这件事的边界要划清楚：AI 不是"独立"完成了所有事情。TencentOS 团队非常明确地强调，安全专家负责方法指导与关键判断——AI 提供的是持续探索与执行能力，最终决策仍由人把关。但这恰好是值得参考的一种工作方式：把"模型能力"放进一个真实的工程流程，而不是单纯比拼模型能不能"答题"。
五、另一种声音：AI 找漏洞会不会让攻防失衡
围绕这件事，外界有另一种声音值得认真对待。
一种比较典型的担忧是：如果 AI 找 0day 变得越来越容易，那防守方是不是反而变得更被动？毕竟漏洞发现节奏加快了，但全网补丁节奏并没有同步加快。在 7 月 27 日之前，SCTPhantom 的修复还没进入 stable 分支，绝大多数生产环境的内核其实都还"裸奔"。
一个佐证是同时间窗口内 Nebula Security 披露的另一个案例——他们的 AI 驱动工具 VEGA 在 Linux 内核里发现了一个代号 GhostLock 的漏洞，编号 CVE-2026-43499。这个漏洞自 2011 年在 Linux 2.6.39 中被引入，潜伏时间长达 15 年，几乎所有主流 Linux 发行版都默认携带，却始终无人察觉。两件事叠在一起看，结论并不让人安心：AI 在挖洞，但发行版的"打补丁周期"并没有相应缩短。（来源：FreeBuf，2026-08；快科技，2026-07-13）
更现实的隐忧是"使用门槛"。过去搞内核漏洞研究，要懂协议、懂堆利用、懂防护绕过，门槛极高；现在一个 bash 脚本加一次 API 调用，90 分钟就能定位到一个可广泛利用的问题。科普中国在 6 月一篇报道里引用了 Thomas Ptacek 的观察："以前想找到一个 Linux 内核零日漏洞，通常需要经验丰富的安全研究员，花上数周甚至数月做高强度审计。现在，一个 bash 脚本，一个 API 调用，90 分钟，AI 就能定位到一个可广泛利用的 SQL 注入问题。"——而这只是 SQL 注入，内核漏洞的"提速"恐怕只是时间问题。（来源：科普中国，2026-06-15）
这种背景下，"漏洞响应起点前移"不再只是一个工程改进，而是一条必须走的路：等 CVE 公告再补补丁，在 AI 时代是远远不够的。
六、从"等 CVE 公告"到"提前修复"
TencentOS 这次把漏洞响应节奏做到了一种新的水平：
- • 7 月 12 日：科维斯 AI 发现漏洞，并于当日构造 KASAN PoC
- • 7 月 14 日：获得 SCTP 子系统维护者 Ack
- • 7 月 15 日—23 日：完成 TencentOS、Debian、Rocky/RHEL、Ubuntu 多发行版提权验证
- • 7 月 23 日：修复补丁合入 Linux 内核主线
- • 7 月 27 日：验证可用于容器逃逸
- • 8 月 3 日：修复进入 Linux stable 分支
- • 8 月 4 日：CVE 编号正式分配
- • 8 月 4 日：TencentOS Server 同日发布内核修复安全公告及软件包
从发现到上游合入主线，11 天；CVE 分配当天，TencentOS 的修复包已经就位。
这背后的方法论并不复杂：当科维斯 AI 完成漏洞发现与危害验证后，安全团队同步启动产品影响研判、补丁回合、内核构建和回归验证。即使 CVE 编号还没下来，产品团队也能依据真实利用证据提前判断风险并推进修复——这种"并行"，才是压缩响应时间的关键。
把它放回行业视角，过去几年我们看到的趋势是：漏洞发现越来越快、越来越自动化，但补丁分发依然严重依赖人工节奏。Linux 内核主线合入补丁是一回事，所有下游发行版把修复推送到生产环境，又是另一回事，中间往往横跨几周甚至几个月。SCTPhantom 的 11 天已经是非常激进的水平，但要把它复制到整个生态，仍需要厂商、安全团队和开源社区一起把"分发节奏"也提速。
七、笔者锐评：科维斯 AI 真正值得参考的，不是"找洞"
聊到这里，笔者想把视角拉到更上层一点。
SCTPhantom 这件事真正值得讨论的，不是"AI 找到了一个 18 年的漏洞"这个噱头——毕竟，厉害的研究员也找得到。真正值得参考的是这套工程化流程：科维斯 AI + Agent Harness 框架 + 多 Agent 协同 + 安全专家研判，四者组合之后，它把"长链路内核研究"这件事变成了一条可复用、可规模化、可验证的工程管线。
从更长远的角度看，安全研究的瓶颈从来不在"模型能不能写 PoC"，而在"研究能不能持续"。一个研究员不可能一周 7 天、每天 12 小时都保持同样的状态，但一套搭好的 Harness 框架可以。Agent 失败了一次没关系，状态被沉淀下来，下一次从失败点继续——这才是真正的"杠杆"。
另一个值得警惕的事情是：这次公布的是漏洞，不是利用代码。 TencentOS 团队明确表示，在主要受影响产品完成修复前，不会公开完整利用代码和可复现攻击的细节。这是一个负责任披露的标准做法，也是行业该有的样子。如果 AI 让漏洞发现提速，但责任披露和修复分发的速度没有同步跟上，那"AI 找洞"这件事的社会收益就要打折扣。
再往远看一步，物理 AI、机器人、自动驾驶——所有依赖 Linux 内核实时性的领域，都会被同样的问题敲到。这次是 SCTP 协议栈，下次可能是网络命名空间、cgroup、io_uring。AI 找漏洞这件事，从 2026 年开始，会从"案例"变成"日常"。发行版团队、安全团队、企业 IT 团队，都得把这件事当作新的常态来安排防御节奏。
最后说一句不那么"技术"的话：AI 在内核安全上走出这一步，让笔者对"AI 能不能替代专家"这件事的看法又变了一次。它替代不了专家，但它能把专家的能力边界往前推一截。把判断交给人，把执行和连续性交给 AI——这可能是接下来几年，安全行业乃至整个工程行业，最值得尝试的一种分工方式。
