Google Vertex AI SDK 漏洞允许攻击者通过存储桶抢占劫持模型上传

Google Cloud Vertex AI Python SDK 中的一个漏洞允许攻击者在无需访问受害者项目的情况下，劫持受害者的机器学习模型上传，并在 Google 的服务基础设施内运行代码。

Palo Alto Networks Unit 42 通过 Google 的漏洞赏金计划发现并报告了此漏洞，将该技术称为“Pickle in the Middle”（中间人 Pickle 攻击），并表示未观察到野外利用。Google 已修复该漏洞；如果您使用该 SDK，请更新至 1.148.0 或更高版本。

攻击者仅需拥有自己的 Google Cloud 项目以及受害者的项目 ID（通常公开）。无需凭证、无需钓鱼、无需在目标中建立立足点。

该漏洞在于 SDK 如何为模型上传选择临时 Cloud Storage 存储桶。如果用户未设置存储桶，SDK 会根据项目 ID 和区域生成可预测的名称，例如 project-vertex-staging-region。它会检查该存储桶是否存在，但不会检查受害者是否拥有它。

由于存储桶名称是全局唯一的，攻击者可以在自己的项目中抢先创建预期的存储桶。受害者的 SDK 随后会将模型文件上传到攻击者的存储桶。攻击者随后可以用恶意模型替换上传的模型。

许多 Python ML 模型使用 pickle 或 joblib 保存，加载文件时可以运行代码。当 Vertex AI 稍后加载被替换的模型时，攻击者的代码将在服务容器内执行。

攻击依赖于速度。Unit 42 测量受害者上传与 Vertex AI 读取文件之间约有 2.5 秒的间隔。在其概念验证中，攻击者使用了一个在上传后触发的 Cloud Function，并在 Vertex AI 读取之前的 1.4 秒内替换了模型。

Payload 随后从服务容器的元数据服务器窃取了 OAuth 令牌并将其发送给攻击者。在 Unit 42 的测试环境中，该令牌不仅限于受影响的部署。它可以访问同一 Google 管理的租户项目中的其他模型工件，包括具有训练权重的完整 TensorFlow 模型，以及 BigQuery 元数据、访问列表、租户日志、GKE 集群名称和内部容器镜像路径。

攻击仅在特定条件下有效：受害者在该区域的默认暂存存储桶尚不存在，且受害者未设置 staging_bucket 参数。对于 Vertex AI 中某区域的新项目，前者很常见。

后者取决于开发者依赖 SDK 的默认值而非命名自己的存储桶。

Unit 42 于 2026 年 3 月 5 日通过 Google 的漏洞奖励计划报告了该漏洞。它测试了当时最新的版本 1.139.0 和 1.140.0，发现两者均存在漏洞。

Google 于 3 月 31 日在 v1.144.0 中提供了初始修复，在存储桶名称中添加了随机 uuid4。它于 4 月 15 日在 v1.148.0 中完成了修复，添加了存储桶所有权验证以阻止 Model.upload() 中的存储桶抢占。截至发布时，Unit 42 和 Google 的 Vertex AI 安全公告均未列出该问题的 CVE。

更新至 1.148.0 或更高版本以激活所有权检查。此外，在上传模型时，将 staging_bucket 显式设置为您控制的 Cloud Storage 位置。由于有缺陷的逻辑位于客户端 SDK 中，请检查运行它的任何地方的 google-cloud-aiplatform 版本，包括 notebooks、CI jobs 和训练管道，而不仅仅是生产服务。

这是今年 Vertex AI 中出现的第二个可预测存储桶名称漏洞。Google 于 2 月修复了 CVE-2026-2473，这是 Vertex AI Experiments 中另一个存储桶抢占漏洞，同样允许跨租户代码执行、模型窃取和投毒。

Unit 42 之前关于 Vertex AI 默认服务代理权限的工作追踪了一条从部署的 AI 代理到客户和租户数据的相关路径。