NastyC2 混进 npm、Salesforce OAuth 再泄露、金融 AI 新规落地：AI 安全战线已扩到数据流

几件事在同一天挤到一起：恶意 npm 包把后渗透工具塞进开发流水线，Salesforce 生态里的第三方 OAuth 集成继续成为数据外流通道，中国金融监管把 AI 安全开发写成专项指导意见；另一边，ProjectDiscovery 把漏洞数量、零日利用和修复速度放到一张时间轴上，结论很刺眼：攻击侧已经按机器速度运转，防守侧还在按人工周期排队。

这不是「多打几个补丁」能独自解决的问题。AI 系统一旦接管代码、客户数据、金融流程和业务决策，企业真正要守住的对象就从单点模型扩展成了整条数据流。

本期速览

漏洞曲线继续上扬：ProjectDiscovery 统计显示，2026 年截至 6 月 3 日已发布 30,550 个 CVE，约为 2025 年全年 49,458 个的 60% 以上；文中同时提示部分 2026 数值为趋势投影。企业含义：AI 辅助发现、生成代码和自动化利用同时推高漏洞处理量，传统排队式修复会越来越慢。1
开发供应链被投毒：三个 npm 包 node-ci-utils@2.1.4、win-env-setup@3.0.6、macos-ci-utils@1.0.0 被曝投递 Rust 后渗透框架 NastyC2，具备 80+ 命令能力。企业含义：CI/CD 里的构建代理往往握有仓库密钥、云凭证和生产权限，包一旦中招，影响不是开发机一台。2
SaaS 集成继续外带数据：ReliaQuest 披露，攻击者通过被滥用的 Klue Battlecards 集成获取 OAuth 令牌，并用 Salesforce REST API 自动化拉取 CRM 数据，至少出现 15 分钟近千次查询和超过 6 小时的持续外带。企业含义：被信任的第三方应用，本质上也是非人身份；它的数据权限需要像管理员账号一样审计。3
金融 AI 监管落地：国家金融监督管理总局 6 月 18 日发布银行业保险业 AI 安全开发应用指导意见，覆盖治理架构、开发测评、数据治理、算力建设、风险管理等 32 项要求。企业含义：AI 不再只是技术试点，正在进入合规、审计、供应链和业务连续性的共同监管框架。4

漏洞不只是变多，而是变得更快

ProjectDiscovery 这篇文章最值得看的不是单个数字，而是两条曲线的错位：一边是 CVE 总量、已知被利用漏洞和供应链恶意包数量上升；另一边是企业修复关键漏洞的周期长期停留在几十天量级。文中引用 Mandiant 的 time-to-exploit 口径称，2018-2019 年漏洞从披露到首次被观察利用的平均时间约 63 天，2023 年缩短到 5 天，2024 年以后均值被零日利用拖到 0 以下；2026 年的 -13 天属于线性投影，不应当当作已测量事实。1

漏洞利用速度与修复速度的缺口 — ProjectDiscovery 将攻击者利用速度与企业修复周期放在同一轴上，显示暴露窗口正在扩大。1

这条曲线对 AI 团队尤其不友好。AI 应用通常把模型网关、向量库、浏览器代理、插件、SaaS API 和 CI/CD 拼在一起，任何一个组件被打穿，都可能把提示词、客户数据、密钥或内部文档送到攻击者手里。漏洞治理在这里不是「修完某个 CVE」就结束，而是要知道一条推理请求从哪里进来、经过哪些工具、能读到哪些数据、最后向哪里写出。

供应链和 OAuth，正在成为同一类风险

NastyC2 的 npm 事件给开发流水线敲了一次警钟。AI Weekly 整理 The Hacker News 的报道时提到，NastyC2 能做 Kerberoasting、DCSync、容器逃逸、云元数据窃取、AMSI/ETW patching 和 SOCKS5 pivoting，能力层级接近 Cobalt Strike 或 Sliver；但目前没有披露下载量、受害组织数量和归因。2

同样是「可信路径」，Klue / Salesforce 事件发生在 SaaS 侧。ReliaQuest 观察到攻击者通过 Klue 集成服务账号生成 OAuth 令牌，再用 Python 脚本枚举 Salesforce 对象并循环拉取记录；Huntress 则确认自己是受影响客户之一，外流数据包括业务联系人、报价和销售相关沟通，不包括威胁情报、客户凭证、支付卡或产品遥测。3 5

Klue 集成被滥用的威胁报告示意 — ReliaQuest 报告把 Klue 集成定位为 Salesforce 数据外带入口，核心风险是受信任 OAuth 身份被滥用。3

两件事看似一件在代码包，一件在 CRM，其实共用同一个弱点：企业把自动化身份当作「后台工具」，却没有把它当作高危主体持续监控。AI 代理继续接入这些工具后，风险还会放大，因为代理会把读、写、调用和总结串成更长的动作链。

提示注入仍在提醒我们：AI 代理不是一个「安全用户」

本周仍值得补上的研究信号是 StakeBench。来自南洋理工、ST Engineering、IBM Research 和 UIUC 等机构的论文测试了真实 Web Agent 场景下的提示注入攻击，264 个基准案例、3,168 次对抗运行中，没有一个攻击目标能被当前代理稳定抵抗；间接提示注入攻击成功率在 41.67% 到 68.16% 之间，直接提示注入在所有配置中超过 79%。6

StakeBench 对 Web Agent 提示注入风险的建模 — StakeBench 将用户、卖家、平台三类受害方放进同一套评测框架，强调提示注入会造成多方受害。6

更麻烦的是，论文提出一种「隐蔽寄生」失败模式：代理仍完成用户交代的任务，但同时推进攻击者目标。对企业来说，这比显性报错更难发现。日志里看到的是一次成功任务，数据侧看到的却可能是越权读取、偏置推荐、异常写入或外部回传。

金融新规把问题说得很直白：AI 安全要进入全生命周期

金融监管总局的指导意见没有停留在「鼓励用 AI」层面，而是把治理责任、开发测评、数据治理、智能算力、风险分类分级、高风险应用准入、人工监督、外包和供应链风险一起纳入框架。新华网报道还提到，金融机构需要加强网络安全、数据安全和个人信息保护，并关注运营韧性和业务连续性。4

这意味着金融机构的 AI 项目会被问几个更具体的问题：模型在哪里运行？数据是否最小化？外部模型和插件如何准入？高风险场景是否有人类复核？如果一个代理调用了 CRM、知识库、邮件或支付流程，谁能证明它没有把敏感信息带到不该去的地方？

从荆华密算视角看：权限治理之外，还要减少明文暴露

今天这些事件共同指向一个判断：权限边界会被拉长，明文数据会被更多自动化环节触碰。补丁、SBOM、OAuth 审计、日志检测和人工复核都必须做，但它们主要是在减少入口、缩短停留时间、提高发现概率；一旦明文已经进入可访问内存、日志、插件或第三方集成，后面的防线都在和时间赛跑。

荆华密算强调的密态推理，价值不在于替代所有安全控制，而是在 AI 推理这条高价值数据流里，尽量把敏感输入和中间态从可直接访问的明文空间拿掉。其公众号 6 月 1 日发布的全链路密态 AI 助手内测招募，定位的正是用户在法律咨询、职场沟通、情绪倾诉等场景里「想用 AI，又担心悄悄话泄露」的问题。7

对企业版系统来说，同样的逻辑会落到更硬的场景：客户资料、合同、财务数据、医疗记录、投研文档、内部代码，都可能被 AI 代理读取和总结。AI 安全的下一阶段，不只是让代理「少犯错」，而是让它即便在执行任务，也不必把最敏感的数据完整暴露给运行环境。