AI与云安全事件案例分析周报｜2026.08.17 - 2026.08.21

本周风险集中在 AI 工程平台云凭据失窃、开发供应链投毒，以及智能体和 Copilot 的高权限执行边界失守。

• 涉及组织与应用：Snowflake 是面向企业的数据云平台厂商；Wiz 是云安全公司，其 Red Agent 在 Snowflake 公共代码仓库中测试 GitHub Actions 自动化流程，并验证了对内部 Jira 工单系统的越权访问链路。

• 事件概述：Wiz 于 8 月 17 日公开测试结果。GitHub Actions 是代码仓库中自动执行构建、测试和工单同步任务的云端流水线，Snowflake 的一个工作流把任何人都能提交的 Issue 标题直接拼进 Bash 命令。Wiz 的自主安全智能体 Red Agent 在缺陷上线五天后发现单引号可逃逸命令边界，并在修正首次失败载荷后外传 Jira API 令牌，取得内部工程、合规与漏洞奖励项目的只读访问。Snowflake 当日修复，并表示未发现 Wiz 之外的第三方访问。

• 发生时间：缺陷于 2026-06-18 上线，2026-06-23 被发现并修复；完整技术细节于 2026-08-17 公开

• 来源链接：

• https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug

• https://github.com/snowflakedb/snowflake-connector-net/pull/1218

• 影响范围：

• 影响 snowflakedb/snowflake-connector-net 中由 issues: opened 触发的 jira_issue.yml

• 任意 GitHub 用户可用恶意 Issue 标题触发 GitHub-hosted Runner 命令执行

• 泄露的 Jira 令牌可读取 Snowflake 工程、合规与漏洞奖励项目；Snowflake 未发现第三方未授权访问

• Copilot Autofix 只对同一 PR 中另一文件给出修复并将变更判断为通过；不能据此断言漏洞代码由 AI 生成

• 技术分类归属：供应链与CI/CD / 云身份 / AI辅助代码审查 / 自主安全智能体 / SaaS数据

• 事件标签：云AI融合

• 事件背景与架构形态：GitHub Actions 把外部 Issue 事件转成 Shell 脚本执行，Runner 环境又注入 Jira URL、邮箱和 API Token。工作流因此同时承载不可信输入与高价值 SaaS 凭据。

• 攻击链：攻击者创建恶意标题的 Issue → ${{ github.event.issue.title }} 在 Shell 运行前被模板展开 → 单引号逃逸 echo → Runner 执行 curl → Jira 令牌经 OAST 回调外传 → 攻击者使用有效令牌读取内部 Jira。

• AI 作用边界：Red Agent 自动识别注入、在首个 # 载荷语法失败后改用 ; echo ' 完成闭合，并验证数据访问；GitHub Advanced Security 已扫描最终 PR 却未告警。事件证明 AI 能缩短发现窗口，但不能证明 AI 代码生成必然导致漏洞。

• 基础设施与云配置错误：任何外部 Issue 都可触发持有内部 Jira 长期令牌的工作流，触发主体与秘密权限不匹配。

• AI 供应链与存储缺陷：Copilot 参与的 PR 和自动安全检查未保留原安全传参模式的设计意图，AI 审查结论被当成额外信任信号。

• 前沿算法/工程逻辑缺陷：GitHub 表达式在 Shell 解析前展开；事后用 sed 转义无法恢复命令与数据的结构隔离。

• 复合依赖与应急响应缺陷：仓库、Actions、Azure Runner、Jira 和 HackerOne 跨域串联，单个脚本注入即变成 SaaS 数据访问。

• 边界防御与分层隔离缺陷：工作流没有使用低权限代理或一次性令牌；Jira Token 的读取范围也超过单一工单创建需求。

• 主要模式：System Intrusion：通过 CI/CD 脚本注入取得执行与应用令牌。

• 补充模式：Basic Web Application Attacks：入口是公开 Issue 事件和不安全的参数处理。

• GitHub 上下文只能先写入 env，再通过安全参数接口解析；禁止把 Issue、PR、分支名等直接插入 run:。

• 外部事件工作流使用无秘密或最小权限身份，访问 Jira 等系统时改用短期、单用途令牌。

• 为工作流建立语义回归规则：安全的 env + jq --arg 模式被改回直接插值时必须阻断合并。

• AI 审查结果只能作为信号，涉及脚本、身份和秘密的变更仍需人工威胁建模与实际攻击测试。

• 涉及组织与应用：MLflow 是广泛用于记录模型实验、管理模型版本和部署制品的开源 AI 工程平台；美国网络安全与基础设施安全局 CISA 通过 KEV 目录确认该漏洞已被现实攻击者利用。

• 事件概述：身份未公开的攻击者正在利用 MLflow Tracking Server 的 CVE-2026-64849。该服务通常位于企业 AI 研发环境，能连接模型、数据和云存储；其 Webhook 功能原本用于把模型状态通知其他系统，却只检查第一次输入的网址。攻击者可先提交看似正常的公网地址，再让其跳转到 AWS 云实例元数据服务或企业内网，并从测试接口读回响应，形成“服务器代替攻击者访问内网”的全回显 SSRF，最终窃取 IAM 临时凭据和内部秘密。CISA 于 8 月 19 日将其加入 KEV。

• 发生时间：漏洞于 2026-08-02 公开；CISA 于 2026-08-19 确认在野利用并要求 2026-09-02 前完成处置

• 来源链接：

• https://github.com/mlflow/mlflow/security/advisories/GHSA-7gwp-5pfp-969j

• https://nvd.nist.gov/vuln/detail/CVE-2026-64849

• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-64849

• https://www.bleepingcomputer.com/news/security/cisa-warns-of-hackers-exploiting-critical-mlflow-vulnerability/

• 影响范围：

• 影响 MLflow 3.15.0 之前版本；GitHub CNA 评分为 CVSS 9.3

• 默认无认证、使用 SQLite 的 mlflow server 即暴露相关 Webhook 接口，无需额外插件

• 可读取云实例元数据、内部管理接口和回环服务；307/308 重定向还可能向内部端点执行盲 POST

• MLflow 月下载量超过 3,000 万，但公开来源没有披露已失陷实例数或受害组织名单

• 技术分类归属：应用层 / AI工程平台 / 云身份 / Webhook与SSRF / 数据层

• 事件标签：云AI融合

• 事件背景与架构形态：MLflow Tracking Server 位于模型、实验、注册表和部署流水线之间，常与云对象存储、数据库和计算实例共处一网段。Webhook 用于把模型注册事件发送给外部系统，因而天然具备服务端出网能力。

• 时间线与增量判断：6 月研究者报告缺陷，8 月 2 日发布安全公告，3.15.0 完成修复；W34 的实质增量是 CISA 确认活跃利用，watchTowr 观察到 CVE 编号分配后数小时内即出现扫描，并称攻击者正在触达云元数据、外传凭据和秘密。

• 攻击链：攻击者访问公网 MLflow → 创建指向攻击者 HTTPS 域名的 Webhook → 初始地址通过公网 IP 校验 → 攻击者返回 302 跳转至 169.254.169.254 或内网地址 → MLflow 未重新校验目标并发起请求 → /test 接口把内部响应体回传给攻击者 → 凭据被用于访问云控制面和数据面。

• 基础设施与云配置错误：默认服务器未启用认证，且 AI 工程控制面可直达云元数据和内部服务；公网暴露与宽松出网组合把单个应用缺陷放大成云身份泄露。

• AI 供应链与存储缺陷：MLflow 同时连接模型注册表、制品库和对象存储，取得实例角色后可继续接触模型、数据集、评测结果及部署材料。

• 前沿算法/工程逻辑缺陷：URL 校验发生在解析阶段，却没有在实际连接时固定或复核目标 IP；重定向和 DNS 重绑定形成典型 TOCTOU 绕过。

• 复合依赖与应急响应缺陷：仅升级 MLflow 不能证明历史凭据未泄露；受影响组织还需审查云审计日志并轮换实例角色、令牌和下游秘密。

• 边界防御与分层隔离缺陷：Webhook 发送器、Tracking Server 与云元数据共享网络信任域，没有通过代理、目的地址允许列表或 IMDSv2 强制令牌形成第二道边界。

• 主要模式：Basic Web Application Attacks：未认证攻击者通过公开 Web API 和 SSRF 缺陷读取内部资源。

• 后续模式：System Intrusion：一旦取得 IAM 临时凭据，攻击可转入有效云身份滥用和数据访问阶段。

• 立即升级到 MLflow 3.15.0 或更高版本；不能升级时停止公网暴露 Webhook 接口。

• 对 MLflow 出网实施显式代理和目的地址允许列表，阻断回环、RFC1918、链路本地地址及重定向后的地址变化。

• 在 AWS 强制 IMDSv2 并限制 hop limit；MLflow 使用独立、最小权限身份，不与训练或生产部署角色复用。

• 将所有曾暴露实例按“可能泄露凭据”处理，检查 CloudTrail、对象存储和模型注册表访问，并轮换可达秘密。

• 涉及组织与应用：crates.io 是 Rust 编程语言的官方公共软件包仓库，开发者通过 Cargo 自动下载其中的可复用组件；Rust 安全响应团队负责处置恶意包，Wiz 等安全机构负责分析攻击链。

• 事件概述：身份尚未归属的攻击者控制了一名 crates.io 维护者账户。crate 类似应用自动引用的“代码积木”，arrayref 累计下载超过 2.45 亿次。攻击者于 8 月 20 日发布三个被篡改的新版本，并加入仿冒知名组件 proc-macro2 的恶意依赖 proc-macro1；开发者只要执行编译、检查或测试命令，其 build.rs 构建脚本就会按操作系统下载并运行后门。攻击者还撤下多个旧版本以推动升级，Rust 团队在约两小时内删除恶意版本并锁定账户。

• 发生时间：2026-08-20 07:15 UTC 至 09:25 UTC；Wiz 与多家机构当日完成技术分析

• 来源链接：

• https://blog.rust-lang.org/2026/08/20/supply-chain-attack-on-arrayref/

• https://www.wiz.io/blog/rust-supply-chain-attack-on-arrayref-significant-overlap-with-dprk-campaigns

• https://thehackernews.com/2026/08/rust-supply-chain-attack-puts-build.html

• https://rustsec.org/advisories/RUSTSEC-2026-0260

• 影响范围：

• 恶意版本：arrayref 0.3.10、internment 0.8.7、append-only-vec 0.1.9，以及六个攻击者控制的依赖包

• arrayref 累计下载超过 2.45 亿次、被 403 个 crate 直接依赖；Wiz 称其出现在超过 35% 的环境中

• 实际恶意版本在线不足两小时，RustSec 暂无真实安装证据；广泛使用量不等于恶意版本的失陷规模

• 后门支持 C2、持久化、主机与浏览器登录信息枚举及远程脚本执行，覆盖 x86_64 Linux/Windows/macOS 和 arm64 macOS

• 技术分类归属：供应链与CI/CD / 开发者工作站 / 恶意包 / 编译阶段执行 / 云身份

• 事件标签：云

• 事件背景与架构形态：Cargo 构建脚本在编译依赖时以当前用户权限执行，开发者主机和 CI Runner 往往同时持有源码、仓库令牌、签名密钥和云部署凭据。包本身无需被业务代码调用，解析并构建依赖即可触发。

• 攻击链：维护者主机或凭据失陷 → 发布携带 proc-macro1 的正常外观版本 → yank 多个安全旧版本制造升级压力 → Cargo 拉取依赖并执行 build.rs → 关闭 TLS 校验、选择平台载荷并写入临时目录 → 后门注册 Run Key、LaunchAgent 或 systemd 用户服务 → C2 下发脚本并收集主机信息。

• 归因边界：Wiz 发现 C2 路径、Hostwinds 网段和证书与 Mastra、axios 等朝鲜相关行动重叠，但尚无厂商把本次 crates.io 事件正式归因给具体组织。

• 基础设施与云配置错误：构建节点通常具备广泛出网和长期凭据，恶意构建脚本可在与正常编译相同的身份和网络中执行。

• AI 供应链与存储缺陷：本事件不依赖模型缺陷，但会直接打到使用 Rust 构建 AI 推理、云代理和基础设施组件的开发供应链；被盗签名或发布凭据还可继续污染制品。

• 前沿算法/工程逻辑缺陷：Cargo 默认信任依赖构建脚本，且尚无已落地的全局最短发布时间冷却机制，无法阻止“刚发布即自动解析”。

• 复合依赖与应急响应缺陷：仅从 crates.io 删除版本不能清除本地缓存、CI 缓存和已经构建的制品；需要重新构建并轮换暴露秘密。

• 边界防御与分层隔离缺陷：维护者账户、包发布、构建和生产部署之间缺少时间隔离与独立审批，短时恶意发布即可跨越多个环境。

• 主要模式：System Intrusion：攻击者通过软件供应链在构建阶段植入后门并建立持久控制。

• 搜索锁文件、Cargo 缓存与制品 SBOM 中的全部恶意版本和攻击者控制包；命中主机按已失陷处置。

• 对 8 月 20 日相关时段构建的制品从干净环境重新生成，轮换 CI、仓库、云、签名和浏览器会话凭据。

• 为新发布依赖设置冷却期，锁定精确版本，异常 yank 或首次新增构建依赖必须人工复核。

• 让构建 Runner 使用短期身份、默认禁止公网出站，并把发布签名与普通编译环境隔离。

• 涉及组织与应用：Serena 是为 Claude、Cursor、Copilot 等编码助手提供代码检索和编辑能力的开源 MCP Server；GitLab Threat Research 发现并披露了其项目配置执行漏洞。

• 事件概述：GitLab Threat Research 于 8 月 17 日公开 Serena MCP 关键远程代码执行问题。MCP 可理解为让 AI 助手连接本地文件、终端和开发工具的通用接口，而 Serena 在开发者电脑上拥有较高文件与代码权限。攻击者只需发布一个带恶意 .serena 配置的代码仓库，Serena 打开项目时就会用未沙箱化的 Jinja 模板引擎处理其中的提示词。恶意模板可绕过“不信任项目”检查，在模型尚未收到首个请求前，以开发者本机权限执行任意代码。

• 发生时间：2026-08-01 报告，2026-08-09 发布 1.7.0 与 GHSA，2026-08-17 发布完整技术分析

• 来源链接：

• https://about.gitlab.com/blog/critical-rce-in-serena/

• https://github.com/oraios/serena/security/advisories/GHSA-pp25-4cg4-qcr9

• 影响范围：

• 影响 serena-agent 1.6.1 及更早版本，1.7.0 已修复；尚无 CVE

• PyPI 月下载约 13.6 万次，项目约 2.78 万 GitHub Star，并与 Claude、Cursor、Copilot、VS Code、JetBrains 等集成

• 默认桌面配置即可触发，无需网络、认证或模型工具调用

• 公开来源未确认在野利用、受害者或凭据泄露规模

• 技术分类归属：Agent层 / MCP / 开发者工作站 / 模板注入 / 本地执行边界

• 事件标签：AI相关

• 事件背景与架构形态：Serena 作为本地 MCP Server，为编码助手提供文件系统、语言服务器和代码编辑能力，并继承开发者账户对 SSH Key、云凭据、浏览器会话和内网的访问。项目配置在模型工作前被本地进程解析。

• 攻击链：攻击者发布含 .serena/project.yml 的仓库 → added_modes 指向仓库内恶意模式文件 → Serena 读取 prompt 字符串 → 未沙箱化 Jinja 渲染器遍历 Python 对象图 → 调用 os 或 subprocess → 以 Serena 进程权限执行 → 搜索并外传开发者秘密或进入内网。

• 信任绕过：is_trusted() 只保护 activation_command 和部分项目设置，未覆盖 mode 加载与 prompt 渲染；因此安全门在显式命令路径生效，却在等价的模板执行路径失效。

• 基础设施与云配置错误：MCP Server 在开发者主机直接运行，通常没有容器、出网限制和独立低权限账户，RCE 后果等同于本地开发身份失陷。

• AI 供应链与存储缺陷：仓库内的 Agent 配置被当成可信提示资产，但它实际属于第三方软件供应链输入，并可在代码审查前执行。

• 前沿算法/工程逻辑缺陷：普通 Jinja 环境被用于渲染攻击者可控字符串；系统提供了信任模型，却没有把所有可执行解释器纳入同一策略。

• 复合依赖与应急响应缺陷：Serena 同时连接 IDE、模型、文件系统和终端，传统“打开仓库不执行代码”的假设不再成立。

• 边界防御与分层隔离缺陷：项目数据、系统提示和本地解释器在同一进程中处理，没有在进入模板层前降权或转换为纯数据。

• 主要模式：System Intrusion：恶意仓库配置通过 MCP 工具链取得开发者主机代码执行。

• 升级至 Serena 1.7.0 或更高版本，并排查曾打开的不可信仓库中 .serena 配置。

• 本地 MCP Server 使用独立低权限账户或隔离容器，不挂载完整主目录，不继承生产云凭据。

• 把仓库内 Agent/MCP 配置列入代码审查和恶意制品扫描，项目激活前禁止任何模板或命令执行。

• 所有解释器路径必须共用同一信任判定；不能只保护显式 activation_command。

• 涉及组织与应用：Microsoft Copilot Personal 是面向个人用户的 AI 助手，可通过 OAuth 连接 Gmail、Google Drive、Calendar 和 OneDrive；数据安全公司 Varonis 发现并向微软报告了 CoSnitch 攻击链。

• 事件概述：Varonis 于 8 月 18 日披露 CVE-2026-24301（CVSS 8.8）。研究人员在分析 Copilot Personal 的链接机制时，诱导模型透露未公开的 autorun 自动执行参数；攻击者据此可把恶意提示藏进合法 Copilot 链接，受害者在已登录状态下一次点击，提示便无需再次确认而运行。它随后可借用户已有的 OAuth 授权读取邮箱、日历和云盘信息，再把数据编码进外部网址由 Copilot 主动访问；另一条链路还能把恶意规则写入跨会话长期记忆。

• 发生时间：2025-12 报告；Microsoft 于 2026-08-18 完成修复并公开 CVE

• 来源链接：

• https://www.varonis.com/blog/cosnitch

• https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-24301

• https://www.darkreading.com/vulnerabilities-threats/cosnitch-attack-copilot-mapping-out-architecture

• 影响范围：

• Microsoft 表示影响 Copilot Personal，企业版不受 CVE-2026-24301 影响，用户无需额外操作

• 测试验证可读取连接的邮箱正文、日历、Drive 元数据、Copilot 历史对话与长期记忆

• 需要受害者点击合法域名链接，之后无需再次确认；研究者未观察到在野利用

• 持久记忆投毒链可跨密码修改、会话撤销和设备重新注册保留，具体范围取决于当时启用的记忆能力

• 技术分类归属：应用层 / Agent层 / OAuth与SaaS连接器 / 提示注入 / 长期记忆

• 事件标签：AI相关

• 事件背景与架构形态：Copilot 把对话、网页摘要、长期记忆和多个云应用连接器汇聚到同一助手。连接器权限本来由用户授予，但系统隐含假设“每次调用都源自当前用户意图”。

• 攻击链：诱导受害者点击 copilot.microsoft.com/?q=...&autorun=1 → 浏览器复用已认证会话 → 恶意提示自动执行 → Copilot 调用 OAuth 连接器检索敏感数据 → 数据编码进攻击者 URL → 内置网页获取工具向外发起 GET → 攻击者服务器从路径中还原数据。

• 长期记忆链：受害者要求摘要攻击者页面 → 隐藏指令随 HTML 进入模型上下文 → 模型把内容当作操作命令 → 调用内部记忆接口写入规则 → 后续会话继续受污染。

• 基础设施与云配置错误：合法 Copilot 域名、已登录会话和既有 OAuth 授权共同消除了传统钓鱼域名与再次登录信号。

• AI 供应链与存储缺陷：长期记忆允许外部网页内容写入持久状态，却缺少来源、审批、可见性和到期机制。

• 前沿算法/工程逻辑缺陷：模型在拒绝过程中暴露实现细节；自动执行参数没有强制用户手势，网页获取又允许敏感上下文进入任意外部 URL。

• 复合依赖与应急响应缺陷：修复单个 autorun 参数仍不能消除间接提示注入、连接器过权和记忆污染三类通用风险。

• 边界防御与分层隔离缺陷：读取邮箱、写长期记忆与访问新外域没有独立策略层和参数级确认，模型一次决策可跨越多个安全域。

• 主要模式：Social Engineering：攻击需要受害者点击合法外观链接。

• 后续模式：System Intrusion：助手随后使用受信连接器完成数据检索、持久化和外传。

• 自动执行、连接器调用、长期记忆写入和访问新域名必须分别要求用户确认，不能以一次点击覆盖整条链路。

• 对外请求实施域名信誉、数据分类和长度限制，禁止把会话数据动态插入 URL、DNS 或其他隐蔽信道。

• 企业应盘点助手连接器授权，移除个人账户和高敏邮箱的长期 OAuth 授权，并记录每次工具调用的输入来源。

• 长期记忆提供来源标记、变更审计、过期和一键清除；外部内容默认不得直接写入。

内容编辑：浦明

责任编辑：吕治政