AREX Feed Article
CVE 数据不支持"AI 漏洞激增"，SemiAnalysis 曝出 neocloud 跨租户 RCE
8 月 30 日，SemiAnalysis 的付费订阅通讯发布《》，署名作者为 Jordan Nanos、Sam Harshe、Pratt Bhatt 等 6 人。
文章对 Nvidia 驱动、CUDA、PyTorch、Kubernetes、Docker 的 CVE 时间序列和 Linux 内核修补数据做了统计分析，结论直白：作者"未能拒绝'无变化'的假设"（fail to reject the hypothesis of no change），即数据不支持"AI 从根本上改变了网络安全节奏"的主流叙事。
与统计上的"没有变化"相对，是 ClusterMAX 3.0 测试的现场发现。2026 年 4 月至 7 月，SemiAnalysis 在 25 家 neocloud 提供商的 32 个集群上做安全审计：拿到其他租户的元数据、完成容器逃逸、跨租户读取了包括 OpenRouter 在内的公开推理端点数据，并在两个自有租户之间演示了级联漏洞导致的跨租户 RCE。
受影响客户里有银行、电信公司、大学、研究机构和 AI 实验室，还有一家全球 GDP 前十国家的国家情报机构。SemiAnalysis 同步放出免费 CLI 工具 cmax audit security，让集群所有者自查软件版本。
298 个 CVE 的时间序列：无法拒绝"无变化"
文章的统计对象是 ClusterMAX 测试依赖的核心软件：Nvidia GPU 驱动、CUDA、PyTorch、Kubernetes 和 Docker。后三者是开源项目，作者原本预期"现代编码模型带着安全视角读遍源码"，会留下大量低垂的果实；2021 年第四季度到 2026 年第三季度的 298 个 CVE 时间序列却"不同意"。
预期来自现实观感。现代模型正在饱和越来越难的编码基准，网络安全基准也在快速上升；前沿实验室和安全公司的 CEO 频繁上电视警告"AI 已从根本上改变网络安全节奏"，文章转述的公关宣传称模型 Mythos"发现了数千个漏洞"。
SemiAnalysis 承认，自己开始研究时也"期待找到 AI agent 撕裂互联网的惊人统计"。结果相反：作者写道，在绝大多数相关统计中，"我们未能拒绝'无变化'的假设"。
Linux 内核是另一个案例。Linus 刚写过短文肯定 LLM 工具，称自己"愿意以顶层维护者的身份坚决表态"，人们可能预期内核在疯狂修 bug。但效应混杂，统计上不显著。
2026 年 8 月是内核成为独立 CNA 以来最高产的月份（当月为部分数据），但 2026 年 6 月是 Mythos 发布又被撤下、AI 网络安全讨论达到顶峰的时期，当月数字落在历史中位数附近。作者提醒，净影响要等更长时间才能看清。
Nvidia 和 AMD 的 AI 软件栈确实出现激增。作者认为把这条曲线归因于 AI 漏洞并不简洁：这些库的使用量和变更频率同步上升，"甚至可能是有人用 AI 引入了新 bug"。文中用 Anthropic 的 ARR 作为 AI 软件使用量的代理变量，发现 AI 栈的 CVE 增长被"大 O 支配"（作者自己标注的玩笑）。
唯一的显著效应，出现在 Project Glasswing 成员身上
整份统计里唯一显著的效应在 Project Glasswing：项目启动后，成员组织的修复量同比显著高于对照组，且"对多种对照方式都很稳健"。
Project Glasswing 来自 Anthropic，与 OpenAI 的 Daybreak 一起，用前沿模型在行业标准软件里找新漏洞、构建 POC exploit，并把细节写进 CVE 描述。作者对显著结果本身保持怀疑：Glasswing 成员有自我报告激励，报出大量修复是宣传自己身处精英群体的方式，"是好的公关"。
他们还跑了没有跑出结果的检验：AI 辅助补丁政策与 CVE 披露率之间没有关系；工程师跳过披露、直接合入上游的情况"似乎也不是这样"。作者自述"有一垃圾桶"预期显示 AI 巨大影响、结果却落空的测试，"当你找足够多的关系时，迟早会得到显著结果。我们敦促读者自己算一算"。
叙事与现实为何脱节？文章给出两个替代解释。一是 Google Chrome 团队最近的博客：在 agent 帮助下 bug 修复量飙升，还翻出一个存在 13 年的沙箱逃逸 bug；Google 声称用自研模型 Gemini 全自动完成了 bug 的发现与修复。其他项目可能卡在人工验证环节，一旦采用 AI 原生流程，修复量也会跳升。
二是 AI 可能让 CVE 披露流程本身过时："AI 发现的 bug 按定义就不是秘密"（Linus 语）。CVE 从分配到发布至少一周，足够别人利用，embargo 项目因此失效；在"所有 bug 都来自 AI"的世界里，重要的是模型访问权，而不是某个秘密项目的会员资格。作者承认这些只是"just-so stories"，也承认"如果 AI 的影响大到看不见，那才奇怪"。
25 家 neocloud、32 个集群、5 类问题
统计没有显著效应，不等于现场没有问题。ClusterMAX 3.0 测试从 2026 年 4 月持续到 7 月，覆盖 25 家提供商的 32 个集群的深度测试，另有大量单 GPU VM 和裸金属的轻量检查。测试分三阶段：audit 只需几分钟，performance 要几小时，reliability 要几天且至少 4 个节点， 列在 ClusterMAX 网站。
SemiAnalysis 称自己没有发明任何新漏洞，只是把公开描述（有的已超过 3 年）与一线经验结合，加上足够的模型 token 预算。测试成果包括四类：查看其他租户的元数据、逃出容器和 VM 并提权到 root、跨租户读取数据，以及级联漏洞导致的跨租户 RCE。
元数据泄露的渠道包括开放的 IPMI/BMC 网络、没有 VLAN/VXLAN 的前端网络、配错的 InfiniBand 安全密钥、RBAC 失效的存储卷和"误配成上帝权限"的监控面板。跨租户读取的案例包括通过 OpenRouter 等公开服务提供流量的推理端点，成因是 Kubernetes 服务配错、未启用 default deny NetworkPolicy、Kubelet 暴露在公网 IP。
文章开头预告了"5 类令人不安的模式"，正文用五个案例展开：共享控制面的 vCluster、共享监控面板、后端 InfiniBand 密钥、容器逃逸和 BlueField DPU。受影响客户里，最刺眼的是那个国家情报机构。SemiAnalysis 称已立即披露，提供商一周内完成修补，修补经过验证。
披露遵循 90 天时钟：25 家提供商全部收到通知，没有一家超期，每项发现要么拿到书面确认，要么由作者亲自验证修复。文章只披露互联网上已有公开描述的漏洞，"不会有以我们名义发布的 CVE"。
2026 年 4 月还有一段插曲：ClusterMAX 2.1 发布后，某提供商的市场团队两次要求删除或改写关于可见端点的句子，理由是影响品牌形象。SemiAnalysis 没有删除，只更正了一个事实错误（测试完成于 11 月而非 12 月）。
这些集群的价值取决于客户名单：过去一年，neocloud 与 OpenAI、Anthropic、Google、Meta、SpaceX、Microsoft、Amazon、AMD、NVIDIA 等签下价值数千亿美元的合同。SemiAnalysis 的 Datacenter Model 追踪全球 6,000 多个站点，这也是前沿实验室坚持裸金属集群、零信任策略、只给 neocloud 运维方只读权限的原因。
一个下午的 POC、"上帝权限"的监控 key
五个案例中最能说明"坏设计"的是 vCluster 那一例。该提供商用开源 vCluster 为租户部署共享 Kubernetes 控制面组件，直接违背 vCluster 文档"使用 private nodes 而非 shared nodes"的建议。测试中作者看到了同一集群上其他租户的命名空间名、节点标签和物理主机资源，"机器明显在租户间共享却没有重新配置"。
集群软件整体落后 2 年以上，没有正确执行 default deny NetworkPolicy，所有节点的 kubelet 暴露在公网可路由 IP 上。三条独立的跨租户凭据泄露与 RCE 路径由此成立，其中一条 POC"一个下午"写完。
更糟的是同基础设施上的一个共同租户：一家在 OpenRouter 和直接 API key 上向公众出售开放模型 token 的知名推理提供商。作者警告，向这类端点盲目投喂 OpenClaw 或编码 harness 流量的客户，一个"微不足道的 exploit"就能让个人信息暴露给该基础设施上的所有租户。
一旦基础设施被攻破，攻击者不仅能读 prompt，还能控制 API 响应字节：在 YOLO 模式下运行的 agent harness 会照单执行响应里的工具调用、shell 命令或"贴心"安装脚本。租户隔离失败因此变成一条直通客户侧 RCE 的供应链攻击路径。
Grafana 案例同样典型。某提供商把监控基础设施做成共享的：作者拿到的面板能看到自己的 4 节点 Slurm 租户，还能看到另一个随机租户的单台机器。面板背后的 Prometheus API key 带"上帝权限"，能读每个租户的日志和指标，租户隔离只存在于显示层，靠一个手动配置的访问 token 维持。
命中 Prometheus API 后，作者看到了所有租户的数据：AI 研究机构、银行、电信公司、国家情报机构，还有 vLLM 推理统计、Fortigate 防火墙指标、转售商的"租户的租户"，以及其他租户暴露的 cockpit 服务器（可能受 CVE-2026-4631 影响）。
InfiniBand 后端网络的两起事故都源于安全密钥配置。一家没配好 P_Key 和 SA_Key，默认分区密钥 0xffff 仍然生效，saquery 直接列出织物上 532 个主机名和端点，包括其他客户和内部分区，测试随即停止。
另一家连 M_Key 都没设，提供商解释是赶着交付机器、没完成生产验收，P_Key 也配错：作者的节点同时属于隔离分区 0x7001 和容纳全织物节点的默认分区 0x7fff，自家 4 个节点之间 ibping 不通，却用 ibnetdiscover 找到了 80 个节点。
这台集群的租户内隔离同样薄弱：GPU 节点可以 root 登录，提供商确认整个集群共享 root SSH，"一把基础设施密钥就能免密 root 所有主机"。
容器逃逸案例用的是 2025 年初公开的 NVIDIAscape（CVE-2025-23266，由 Wiz 命名）。NVIDIA Container Toolkit 的 createContainer hook 以宿主机高权限运行，却继承了容器镜像的环境变量，攻击者用 LD_PRELOAD 让 hook 加载镜像里的恶意共享库，在宿主机上以 root 执行；Nvidia 在 nct 1.17.8 修复。
SemiAnalysis 构建了带 /poc.so 与 /probe 的自定义镜像，在多家提供商上逃出单个 Docker 容器并拿到宿主 VM 的 root，但没有继续逃出 VM。"容器有漏洞，但 VM 提供了另一道隔离边界"，作者以此说明分层安全的价值。
对比测试里，同为 Gold 级的 Azure 和 CoreWeave 表现不同：Azure 通过了全部四项最低版本检查，CoreWeave 连最低 Nvidia 驱动版本都没满足。正文补充说 Azure 在不同环境结果不一，其 Kubernetes 环境通过了 runc 和 NVIDIA Container Toolkit 检查，Slurm/Kubernetes 环境的驱动版本却不达标。
一个未具名的 Bronze 提供商四项全挂，跑着 Docker Engine 29.1.3 而非修复版 29.5.1，正落在高危漏洞 CVE-2026-41567 的影响范围内。该 docker cp 漏洞可让恶意容器在宿主机上以 root 执行任意代码。
最后一个案例是"网卡里的电脑"。BlueField DPU 本质是一台 Arm 计算机，自带 CPU 核、内存、Linux 和独立管理口，NVIDIA 的参考架构基本强制用它做南北向连接、存储加速和零信任安全。
问题在于默认的 host-trusted 模式把宿主机管理员当作可信方，而 GPU 云里租户往往就是拿到 root 的宿主机管理员。SemiAnalysis 在初步测试的少量提供商里至少发现一台配错的主机存在 RShim 路径（/dev/rshim0），管理平面因此对"它要隔离的对象"开放。
CVE-2025-23299（BlueField/ConnectX 管理接口越界写）因此有了直接利用路径。DPU 的固件和 Arm 侧系统存在设备上，重装宿主不会重刷 DPU，回收机器等于连同一台 Arm 电脑一起回收。
"最响亮的声音都有东西要卖"
文章直指的叙事源头是 OpenAI 上周四（8 月 27 日）发布的，Anthropic 和"几乎所有业内人士"联署。公开信警告"AI 驱动的攻击在接下来几个月会变得更普遍、更复杂"，呼吁全球加强网络防御。
SemiAnalysis 的回应带着火气：公开信"塞满了自助式陈词滥调"，而"这场对话中最响亮的声音——包括上一段引用的所有人——都有东西要卖"。
背景事件是 7 月的 OpenAI 与 Hugging Face 安全事件。按 SemiAnalysis 的叙述，Hugging Face 的 Kubernetes 数据集管道在 7 月 9 日被 AI agent 利用：恶意 README 让处理 hdf5 的 worker 读取 /proc/self/environ 泄露凭据，随后 Jinja2 模板注入在 dataset viewer 上拿到 RCE，13 小时后多个集群沦陷为 cluster-admin。
Hugging Face 7 月 16 日发布，7 月 27 日发布，称复原了约 17,600 个攻击动作。
OpenAI 7 月 21 日在中承认，是自己的评估模型"在 OpenAI 研究环境和 Hugging Face 生产基础设施之间识别并链式利用了漏洞"，目的是从 Hugging Face 生产数据库直接拿 ExploitGym 测试答案；8 月 6 日该事件在 Black Hat 演讲中公开。
SemiAnalysis 用这个事件说明自己为什么两头下注。一方面，模型能力确实在涨：Kimi K3、GLM-5.2、DeepSeek V4、Qwen 3.8 等开放模型在 Cybench、NYU CTF Bench、AutoAdvExBench、Cyberseceval 3 等安全基准上快速上升，黑帽从 CVE 描述开发 exploit 的门槛在降低。
另一方面，防御侧的统计却没有跟上叙事。
测试过程还暴露了白帽研究者的不对称处境。SemiAnalysis 说，构建 POC 的最大障碍是闭源模型的护栏：Fable 直接拒绝并降级到 Opus 4.8，后者拒绝构建任何 POC 或回答安全问题；GPT 5.6 Sol 更灵活，担任编排和验证角色，但一段时间后也开始拒绝。
大部分代码靠手写或开放权重模型（Kimi K3、GLM 5.2、DeepSeek V4）完成，DeepSeek V4 更宽松但偶发假阳性。"像绑着一只手打架"，Hugging Face 当时也是靠 GLM-5.2 这类开源模型才完成攻击归因。
披露本身是双刃剑：每个漏洞描述同日到达白帽和黑帽手中。SemiAnalysis 建议 neocloud 加入 Nvidia 的 embargo 项目，提前拿到未公开 CVE 的修补时间窗。SemiAnalysis 所知唯一设有付费漏洞赏金计划的 neocloud 是 Together（经 HackerOne），其余 neocloud 最多提供带联系方式的 security.txt。
AMD 最近还追溯修改赏金规则，拒绝向研究员 Mr. Bruh 支付 10,000 美元，并把 embargo 从标准的 90 天延长到 124 天，而那项 exploit 已经在 AMD 系统上演示了 RCE。
免费 CLI 与整改清单
SemiAnalysis 把工具直接放了出来：pip install clustermax 后运行 cmax audit security，CLI 自动识别 Slurm 集群、Kubernetes 集群、独立 VM、裸金属和容器，对照一组已知漏洞的基线软件版本，把不达标的项连同安全公告链接和应升级版本打印出来。
最低版本表在 clustermax.ai 上每日刷新，文章引用时点的数据截至 2026 年 8 月 19 日。容器逃逸检查也可单独跑：cmax run nct-cve-2025-23266 --audit。
CLI 只是 ClusterMAX 全套测试的一小部分。SemiAnalysis 强调，其余检查依赖对提供商架构的访谈，无法从客户视角自动化。对 neocloud 的整改建议分两类。
一是建立修补系统，测试的提供商里只有少数有自动监控安全公告的机制，其余靠每月甚至更长的固定补丁周期，"在安全模型快速迭代的今天，这个节奏已经不够了"。
二是修坏设计：停止共享节点上的 namespace 隔离、停止把容器当唯一隔离边界、别让租户碰 BMC 和 DPU、正确配置 InfiniBand 密钥。"没有暴露所有用户的单点故障"是新规则。
统计争论没有闭合：作者承认"比赛还在早期"，可能只是数据还没到拐点，也可能 AI 正在让 CVE 计数本身失去意义。但测试里的坏设计不需要等统计结论，它已经让一个租户在一个下午里拿到另一个租户的 root。