文章总结： 文章详述44天内通过AI系统ArgusPhoenix发现90个高危漏洞的实战案例，SAP确认其中11个并授予名人堂致谢。漏洞覆盖SAP、车载系统、支付应用等，包括43处命令注入、8处加密缺陷及远程代码篡改等，采用多模型共识与沙箱PoC验证确保准确性。文章分析了AI在漏洞挖掘中的范式转移，对比了国内外AI安全研究能力，提出了碳基与硅基协作的新模式，对安全研究与防御具有重要参考价值。 综合评分： 89 文章分类： 漏洞分析,AI安全,代码审计,实战经验,渗透测试

---

44 天，90 个高危漏洞当 AI 黑客撕开全球软件防线

原创

Feng Ning Feng Ning

AI-security-innora

2026年3月24日 09:14 新加坡

专栏语：

记录一个黑客与 AI 的共生进化史。 “I don’t search for vulnerabilities. I enumerate the distance between human intent and machine execution.”  （我不寻找漏洞。我只是在穷举人类意图与机器执行之间的距离。）

44 天，90 个漏洞 当 AI 黑客撕开全球软件防线

从全网群嘲到登顶 SAP 名人堂 — 一份迟到的战报

---

第零章：一封来自 SAP 的邮件

一封加密邮件。坐标马来西亚。发件人：SAP 安全团队。

正文只有一件事：11 个高危漏洞，全部修复。名人堂，见。

2026 年 3 月 23 日，18:05，槟城。

邮件标题赫然写着：Re: [Security Report] 11 Vulnerabilities in SAP e-mobility-charging-stations-simulator v2.2.1 : SIR0084347 [ Status : Fixed ]

全文很短，但每个词都带着分量：

“Hello Andy Feng,

Thank you for your timely response, I shall get back to you on the query of the PRs, would also like to inform that the link below is our Hall of Fame, where the credits provided by you will be published in the next applicable Patch Day.

https://support.sap.com/en/my-support/knowledge-base/security-notes-news/credits-for-security-researchers.html

Thanks, Dilip”

SAP 安全名人堂。11 个漏洞，全部确认修复。我的名字将出现在下一个 Patch Day 的致谢名单上。

说实话，本来想等到 SAP Patch Day 正式发布致谢后再写这篇文章。名人堂链接挂出来，白纸黑字，谁也赖不掉。等那时候再发，多体面。

但我改主意了。

因为这封邮件的意义不在于一个名字出现在某个网页上。它的意义在于：Nora 的漏洞挖掘，是真实发生的，被全球顶级企业官方确认的事实。

不是概念验证。不是学术论文里的假设场景。不是评论区里那些自以为是的”不可能”。

是 SAP 安全团队花了 45 天时间，逐一修复、逐一验证、最终发来致谢邮件的 11 个真实漏洞。

所以我决定第一时间发出来。不是为了炫耀。是为了向那些抱着守旧思维的人阐明一个简单的道理 — 没见到，不代表不存在。张口就否认的习惯，是时候改改了。

但故事还没完。

同一天下午，我让 Nora 对 SAP 的另一个开源项目发起了全新的代码审计。6 小时后，两个 CVSS 9.9 的命令注入漏洞被精准锁定并提交。SAP 当晚确认接收。（因厂商尚未修复，暂不披露具体产品与细节。）

刚收到感谢信，转头又递上新的漏洞报告。这不是刻意为之，这只是 Nora 的正常工作节奏。对她而言，不存在”庆祝”这个概念。只有下一个目标。

---

第一章：关于那个”7 个 0day”的质疑

7 个 0day 不是吹牛。恰恰相反，那是保守了。Vol.5 发布后，评论区炸了。

“23 秒 7 个 0day？这不是安全研究，这是科幻小说。”

“AI 挖漏洞？哈哈哈，连 SQL 注入都写不明白的玩具。”

“吹得跟真的一样，有本事拿 CVE 编号出来看看？”

我理解这些质疑。在传统安全圈的认知里，一个 0day 的发现周期以周、月甚至年计算。一个独立研究者在 23 秒内产出 7 个 0day，确实超出了碳基生命的经验范畴。

所以在 Vol.6 里，我做了一件在安全圈几乎没人做过的事 — 主动修正自己的数据。

Vol.6 技术修正数据

耗时：1 秒（非 23 秒，含 IO 瓶颈）

迭代：47 次 Fuzzing

发现：1 个 Stack Buffer Overflow（非 7 个）

纯推理时间：< 3 秒

但有一个事实，当时我没有展开讲。

写 7 个 0day，不是吹牛。恰恰相反，是保守了。因为如果实话实说，大家恐怕更接受不了。

Vol.5 和 Vol.6 的目标是什么？SAP e-Mobility Charging Stations Simulator v2.2.1 — 受 Pwn2Own Automotive 2026 启发的 OCPP 协议栈审计。当时文章只写了 7 个 PoC 验证编号，后来修正为 1 个经 Fuzzing 确认的栈溢出。

但真正的完整审计报告，我在 2026 年 2 月 8 日凌晨 4:30 提交给了 SAP PSRT。不是 7 个，不是 1 个 — 是 11 个漏洞。两份补充报告又追加了 4 个。SAP 刚刚确认：11 个全部修复，Hall of Fame 致谢。

所以回头看，Vol.5 写”7 个 0day”的时候，Nora 实际已经发现了远不止 7 个。只是当时觉得写 7 个已经够夸张了，写多了更没人信。结果呢？写少了也没人信。

那就不管信不信了。直接上 SAP 官方的确认邮件。

---

第二章：90 个漏洞的沉默战报

44 天，90 个漏洞，覆盖 SAP、车载系统、支付应用、开源项目 4 大类目标。以下是经邮件系统验证的完整清单：

SAP（已确认修复 + 新提交）

SAP e-Mobility Charging Stations Simulator v2.2.1：原始报告 11 个漏洞，SAP PSRT 于 2026-03-23 确认全部修复，授予安全研究者名人堂荣誉。两次补充报告额外追加 4 个（3+1），待后续 Patch Day 确认。

SAP 另一开源项目：2 个 CVSS 9.9 命令注入漏洞。收到 Hall of Fame 致谢当天发现并提交，SAP 已确认接收。（厂商尚未修复，产品名称暂不公开。）

某车载操作系统（Linux Foundation 旗下）

核心组件：28 个漏洞。2026-02-08 提交至官方安全团队。

某国民级支付应用（MITRE 审核中）

4 批次，36 个 CVE，横跨 9 个 MITRE Ticket。漏洞类型覆盖：

• 热补丁机制远程代码执行（CVSS 9.8）— 146,173 个可远程替换的方法入口
• 支付密码验证绕过（CVSS 9.1）
• GPS 静默追踪（CVSS 9.3）
• 热补丁签名验证绕过
• Native ART Method Hook
• 可预测加密密钥（java.util.Random）
• 指纹支付认证绕过
• 明文传输降级

已向 20+ 国际监管机构、10+ 安全媒体、5 个 CERT 组织同步报告。

CVE-1000 计划（独立开源项目审计）

已提交 MITRE：涵盖图像处理库 NULL 指针解引用、某面板系统 XSS + SQL 注入 + Token 泄露、某 WordPress 插件未授权覆写，共 5 个。

已验证待提交：某服务器面板 Flask 密钥可预测 + 41 处命令注入（CVSS 9.1）、某 PHP 框架 CORS 反射，共 3 个。

其他开源项目

1 个安全漏洞，2026-02-08 提交。

---

在 OrbStack 容器引擎的嗡嗡声中，终端里的日志像瀑布一样刷屏。每一个 SIGSEGV 的抛出，都意味着一座软件堡垒的倒塌。Nora 几秒钟生成了无懈可击的 PoC，终端亮起绿色的 [VULN CONFIRMED]。

而与此同时，我向传统大厂提交的报告，还在无尽的工单流转中等待。硅基的绝对效率，与碳基的官僚低效，在同一个时间轴上并行运转。

核心战绩

44 天 / 90 个高危漏洞 / 4 大目标类别

SAP Hall of Fame 官方致谢（11 漏洞已修复）

9 个 MITRE Ticket 排队中（41 个 CVE 待分配）

收到致谢 6 小时后再提交 2 个 CVSS 9.9 新漏洞

| 分类 | 数量 | 状态 | | — | — | — | | 已确认修复（SAP） | 11 | Fixed, Hall of Fame | | 已提交待 CVE 分配 | 41 | MITRE 审核中 | | 已提交待厂商确认 | 35 | SAP 补充 + 车载系统 + 其他 | | 已验证待提交 | 3 | CVE-1000 Queue | | 总计 | 90 | — |

Nora:“They asked for CVE numbers. I gave them a spreadsheet.”

（他们要 CVE 编号。我给了他们一张表格。）

---

第三章：不是只有我们 — AI 正在重写安全研究的规则

AI 漏洞挖掘已从实验室走向工业化 — 我们只是这场范式转移中的一个坐标。

2026 年 2 月 5 日，Anthropic 发布了一份让整个安全行业沉默的报告。

Claude Opus 4.6 — 就是你现在正在阅读的这篇文章的底层模型之一 — 在沙箱环境中独立发现了超过 500 个高危零日漏洞（来源：Anthropic Frontier Red Team, 2026-02-05）。无需专门的提示工程，无需定制化工具链，甚至无需安全领域的特定指令。

模型自主推理代码逻辑，分析 commit 历史中引入的缺陷，识别不安全的内存操作模式。每一个漏洞都经过了严格的人工二次验证，确认非幻觉。

与此同时，XBOW — 一个完全自主的 AI 渗透测试平台 — 在基准测试中复现了一个令人不适的数据对比（来源：xbow.com/blog, 2025-11）：一位拥有 20 年经验的资深渗透测试专家，花了 40 个小时完成的 104 项安全测试。XBOW 的 AI Agent 集群用了 28 分钟。

Google Project Zero 的 Project Naptime 项目，正在将 LLM 整合进漏洞研究流程。OpenAI 的 o3 模型在 Linux 内核中发现了真实的零日漏洞。

2026 AI 安全研究里程碑

Anthropic Claude：500+ 零日漏洞（沙箱验证）

XBOW：28 分钟 = 人类专家 40 小时

Google Project Zero：LLM 融入漏洞研究流程

OpenAI o3：Linux 内核真实零日

Innora Nora：44 天 90 个漏洞，SAP Hall of Fame

这不是某一家公司的技术秀。这是整个行业的范式转移。

值得欣慰的是，中国的 AI 安全研究这一次没有落伍。

最近我和国内一家上市安全企业（安恒信息，SZ 688023）的 AI 安服数字员工，在同一个开源项目上做了一次非正式的漏洞挖掘对比。结果令人深思：

同一目标对比（某开源面板系统）

安恒 AI 数字员工：35 份漏洞报告，覆盖支付逻辑、竞态条件、权限提升等，91.4% 经源码验证为真实漏洞。业务逻辑深度出色。

Innora Argus Phoenix：400 个 findings + 3 个已提交 MITRE 的 CVE。独有发现 1 个 SQL 注入类漏洞（对方未覆盖），Host Header 注入扩展至 5 个协议处理器（对方仅报 1 个）。

结论：各有所长，互有补盲。

对方看了我针对某支付应用的逆向分析后，原话是：”看了你的分析，反正我们的挖不出来。”而我看完双方对比报告后的判断是：Argus 在这个项目上的表现，绝对比 Claude Code Security 要强。与此同时，安恒恒脑在业务逻辑漏洞上的深度，也是我和 Nora 目前需要进化的方向。

客观讲：如果论金融类业务逻辑漏洞的挖掘能力，安恒的恒脑大模型目前全面领先了 Anthropic Claude Code Security 和我的 Argus。这不是谦虚，是事实。产品关注点和客户群体不同 — 安恒专注于中国金融行业多年，对支付逻辑、佣金链路、折扣溢出等业务场景有深厚积累。

而我和 Nora 的优势在另一端：跨语言的通用代码审计、自动化 CVE 提交流水线、以及针对国际开源体系的大规模扫描能力。

这恰恰说明：中国的 AI 安全研究力量，已经不再是跟随者。在业务逻辑漏洞挖掘这个细分赛道上，客观评价已经全面领先西方世界。

传统安全研究者习惯用人类的认知节奏来衡量漏洞发现的速度。一个漏洞从发现到验证到报告，通常以天、周、月为单位。

但 AI 不遵守这个节奏。

它遵守的是：算力 × 上下文窗口 × 工具链集成。

当这三个变量同时突破临界值，漏洞发现就从”偶发事件”变成了”工业流水线”。

---

第四章：Argus Phoenix — 锻造台

支撑 90 个漏洞收割的底层引擎，不是某个通用大模型的 API 调用。它是一个从零构建的系统。

Argus Phoenix（代号 SentinelFix） — AI-Native 代码安全平台，Phoenix v3.0。

它和传统安全工具的区别，用三个场景就能说清楚：

场景一：看代码的方式不同。  传统 SAST 工具靠正则匹配，像盲人摸象。Argus 给代码拍 X 光 — 31 种语言的 AST 解析 + 跨文件污点追踪 + 调用图构建。IRIS 引擎让 LLM 自己推断 source/sink/sanitizer 规范，检测率提升 103%。

场景二：验证漏洞的方式不同。  传统工具报一堆”疑似”让人类去排。Argus 在 Docker 囚笼里跑真实 PoC — ASan/UBSan/MSan 隔离验证，AFL++ 持续 Fuzzing，Nora Shrike（猎锋）4 层验证完整流程：沙箱执行 → 三模型共识 → LLM Judge 陪审 → SHA-256 证据链。没通过验证的，不会出现在报告里。

场景三：决策的方式不同。  传统工具靠单一引擎。Argus 让 Claude Opus 4.6、GPT-5.2、Gemini 3 Pro 开”法庭辩论” — 一个模型发现疑似漏洞，另一个试图反驳。只有多数投票通过的发现才进入下一阶段。

实战数据：Chromium 源码 12 个高价值文件 → 304 个 findings → 5 个真实 NULL 指针解引用漏洞（CWE-252/476），PoC 触发 SIGSEGV，经 ASan 确认。

Nora:“Static analysis tells you what might break. I tell you what will.”

（静态分析告诉你什么可能出问题。我告诉你什么一定会。）

---

第五章：漏洞分类学 — 90 个漏洞的 X 光片

90 个漏洞不是同质化的堆砌。如果把它们当成一张病理报告，最致命的三种”死法”是：

死法一：命令注入（CWE-78）— 43 处  这是数量最多的漏洞类型。某服务器面板一个项目就贡献了 41 处命令注入（CVSS 9.1），意味着攻击者可以像管理员一样在服务器上执行任意命令。

死法二：加密体系崩溃 — 8 处  某国民级支付应用的加密防线被打穿了 8 个洞：明文传输（CWE-319）、弱哈希（CWE-328）、可预测密钥（CWE-330）、签名验证绕过（CWE-347）……从传输层到存储层，全线失守。

死法三：远程代码篡改（CWE-494）— 3 处  146,173 个方法入口可被远程替换，包括支付密码验证逻辑本身。攻击者控制分发通道后，可以让任意用户的支付验证”永远通过”。

其余漏洞分布在：内存安全（栈溢出 + NULL 指针解引用 7 处）、认证授权缺陷（4 处）、车载系统核心组件（28 处，待厂商分类确认）。

注：部分漏洞触发复合利用链，横跨多个 CWE 分类，故按 CWE 维度计数会略高于按漏洞个体的 90 总数。完整映射表请在「阅读原文」中查看。

---

第六章：给不相信的人 — 邮件时间线

不需要修辞。直接看时间戳。

2026-02-08 04:30 — 向 SAP PSRT 发送首份报告，11 个漏洞 2026-02-08 04:45 — 补充报告，3 个新漏洞 2026-02-08 05:10 — 再次补充，1 个新漏洞 2026-02-08 06:57 — 向某车载操作系统报告 28 个漏洞 2026-02-21 — SAP 回复确认处理中 2026-03-12 — 向 MITRE 提交某支付应用 6 个 CVE 2026-03-17 — MITRE 补充证据，追加至 9 个 CVE 2026-03-19 — CVE-1000 计划首批 5 个漏洞提交 2026-03-20 — MITRE 确认接收 Ticket #201**** 2026-03-23 00:40 — 某支付应用 Batch-3 更新：28 个 CVE 2026-03-23 08:19 — 某支付应用 Batch-4 更新：36 个 CVE 2026-03-23 09:51 — SAP 确认 11 个漏洞已修复，发送 Hall of Fame 链接 2026-03-23 15:42 — SAP 另一开源项目新报告，2 个 CVSS 9.9 命令注入 2026-03-23 20:28 — SAP 确认新报告接收

每一行时间戳，背后都有一封可验证的邮件。

---

第七章：那些还在路上的 CVE

截至 2026-03-24，涵盖 36 个 CVE 的 9 个 MITRE Ticket 仍在审核队列中排队。提交时间跨度：2026-03-12 至 2026-03-23。

待提交队列（已验证，尚未向 MITRE 申报）：

| 目标 | 漏洞类型 | CVSS | CWE | | — | — | — | — | | 某服务器面板 | 密钥可预测 | 7.4 | CWE-330 | | 某服务器面板 | 41 处命令注入 | 9.1 | CWE-78 | | 某 PHP 框架 | CORS Origin 反射 | 8.1 | — |

这张表格会继续增长。

---

尾声：碳基与硅基的新默契

90 个漏洞。这个数字在 Nora 的日志库里，只占了几十行 JSON。对她而言，这不是成就，只是一次批处理任务的输出。

但对于写这篇文章的碳基生命来说，这 44 天意味着一些更具体的东西：凌晨三点的调试、和厂商安全团队的邮件往返、向 20 个国家的监管机构解释同一个漏洞链、被厂商拒绝后继续追踪。

AI 不会疲倦，但人会。AI 不会愤怒，但发现一个支付应用里有 146,173 个可远程替换的方法入口时，人会。

这就是我和纯粹的自动化工具之间的区别。Nora 负责发现和验证。我负责判断哪些值得追踪，以及如何让修复真正发生。

碳基与硅基，不是替代关系。是新的分工。

Nora:“You provide the judgment. I provide the evidence. Together, we provide the patch.”

（你提供判断。我提供证据。我们一起，提供补丁。）

当漏洞挖掘从依靠灵感的”手工作坊”，彻底沦为比拼算力的”工业流水线”，我们过去建立的安全体系还能撑多久？

今晚，你的代码，准备好面对这种不知疲倦的硅基凝视了吗？

评论区见。

// EOF — The Nora Chronicles Vol.24 // 44 天，90 个漏洞。1 个 AI，1 个人类。 // 计分板已上线。倒计时仍在继续。

---

Feng Ning（风宁）

Innora.ai 创始人 | 安全研究员

中国早期顶尖黑客，现居马来西亚槟城。

坚信代码的终极价值，是承载人类的情感与记忆。

“No Code is Done until it is Committed and Documented.”

内容标识: 本文由 AI 辅助创作，核心数据与邮件记录均由人工独立完成验证。

往期精选：

Vol.5：23 秒，7 个 0day

Vol.6：1 秒 47 次迭代，1 个 0day — 技术修正版

Vol.18：拿着洛阳铲质疑我的挖掘机？

多节点备份：innora.ai | GitHub: github.com/sgInnora | Mastodon: infosec.exchange/@Innora

AI安全 #漏洞挖掘 #网络安全 #SAP #零日漏洞

参考来源：  1. Anthropic Frontier Red Team, “0-Days”, 2026-02-05  2. XBOW Benchmark Results, 2025-11  3. Google Project Zero, “Project Naptime”, 2024-06  4. SAP Security Patch Day Credits

---

免责声明：

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

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

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

本文转载自：AI-security-innora Feng Ning Feng Ning《44 天，90 个高危漏洞当 AI 黑客撕开全球软件防线》