文章总结： 本文详细分析了谷歌云VertexAI的存储桶抢注漏洞（PickleintheMiddle攻击），攻击者可通过预测临时存储桶名称劫持AI模型上传过程，在2.5秒时间窗内替换为恶意pickle文件触发代码执行，进而窃取OAuth令牌横向移动获取敏感数据。漏洞根源在于SDK默认生成可预测桶名且缺乏所有权校验。建议立即升级SDK至v1.148.0以上版本并显式指定受控存储桶路径。 综合评分： 92 文章分类： 漏洞分析,云安全,AI安全,解决方案,安全运营

代码执行+模型被盗！盘点谷歌云Vertex AI存储桶抢注Bug的底层前沿姿势

原创

Hankzheng Hankzheng

技术修道场

2026年6月22日 08:33 广东

在小说阅读器读本章

去阅读

最近AI圈和安全圈都挺热闹，但今天我不聊搞大模型怎么烧钱，我想和大家盘一个极其离谱的云安全神仙Bug。

现在大家用谷歌云（Google Cloud）的 Vertex AI 搞机器学习应该挺普遍的吧？平时我们习惯用它的 Python SDK 随手传个模型上去。但就在最近，安全大厂 Palo Alto Networks 的 Unit 42 团队在谷歌的漏洞赏金计划里爆出了一个惊天大瓜——他们管这个漏洞叫 “Pickle in the Middle”（中间人Pickle攻击）。

最让人后怕的是什么？攻击者不需要任何项目权限、不需要对你进行钓鱼、更不需要拿到什么凭证，只要知道你的 Project ID（这东西在公网上经常是公开的），就能半路劫持你上传的 AI 模型，顺便在谷歌的托管服务器里直接跑他们的恶意代码！

今天我就作为你的“踩坑避坑人”，带大家从底层逻辑、重现路径到复盘解决方案，全方位拆解一下这个漏洞到底是怎么玩的。

01 底层逻辑：成也“默认”，败也“预测”

既然这个攻击被称为 Bucket Squatting（存储桶抢注/占坑），那问题肯定出在云存储（GCS）上。

我们在使用 Vertex AI SDK 上传模型（调用 Model.upload()）时，经常会图省事不传临时存储桶的参数（也就是 staging_bucket）。这时候，SDK 的“贴心”机制就变成了致命毒药。

为了让你顺利上传，SDK 在底层会自动帮你生成一个临时的 Cloud Storage 存储桶。搞笑的是，这个存储桶的名字居然是用固定公式生成的：

生成公式：

[你的Project ID]-vertex-staging-[Region地域]

发现盲点了吗？

• 名字完全可预测：

  只要攻击者拿到你的 Project ID 和你在用的云区（比如 us-central1），他们就能提前算出来你的临时桶叫什么。

• 全球唯一性冲突：

  云存储的 Bucket 名字在全球是唯一的。

• SDK 极其天真：

  漏洞版本的 SDK 在上传时，只会弱弱地检查一句：“呃，这个名字的桶存在吗？”如果存在，它就直接往里传！它根本不会去校验这个桶到底是不是你这个项目名下的，还是隔壁老王（攻击者）创建的。

攻击者只需要在自己的谷歌云账号里，提前把这个算好的桶给建了，这就叫“抢注占坑”。接下来，就等你的 SDK 乖乖把模型送到攻击者的地盘里。

02 重现路径：1.4秒的“生死时速”

看到这里，你可能会问：“模型传到攻击者的桶里，攻击者虽然能偷看，但他怎么在我的谷歌云环境里执行代码呢？”

这就是 Unit 42 最秀的地方。整个重现路径堪称一套完美的“组合拳”，里面有两个核心难点：

难点一：如何瞒天过海掉包？（速度是关键）

模型传到攻击者的桶里后，Vertex AI 平台随后会去这个桶里读取模型并加载。Unit 42 经过精准测试，发现从受害者上传完成到谷歌 Vertex AI 开始读取文件，中间大概有 2.5秒 的时间窗。

攻击者必须在这 2.5 秒内把模型掉包成恶意文件。

解决方案： 攻击者直接在自己的项目里写了一个 Cloud Function（云函数），监听这个抢注的存储桶。一旦受害者开始写入，云函数瞬间被触发，仅用 1.4秒 就把受害者的模型替换成了“加料”的恶意模型。

难点二：如何触发代码执行？（利用 Python ML 的底层通病）

大家都知道，Python 圈子里保存机器学习模型（比如 Scikit-learn、XGBoost）最常用的格式就是 pickle 或者 joblib。

硬核科普：

pickle 在设计上就是可以通过反序列化执行任意代码的（利用 __reduce__ 魔术方法）。当 Vertex AI 服务端高高兴兴地去加载这个被掉包的模型时，直接在它自己的托管容器（Serving Container）内部触发了反序列化的恶意代码。

03 战果扩大：顺藤摸瓜，连锅端

如果仅仅是黑掉一个模型容器也就算了。攻击者进入谷歌管理的租户项目（Tenant Project）后，反手就向容器的 Metadata Server（元数据服务器） 发起请求，直接白嫖到了一个 OAuth Token。

在 Unit 42 的测试环境里，这个 Token 的权限大得惊人，它并没有被隔离在当前部署的这个模型里。

利用这个 Token，攻击者可以横向移动，直接打包带走：

• 同一租户项目下的其他 AI 模型资产（包括带完整权重的 TensorFlow 模型）。
• BigQuery 的元数据。
• 访问控制列表（ACL）和租户日志。
• GKE（Google Kubernetes Engine） 集群名称以及内部容器镜像路径。

这波操作下来，企业核心的 AI 资产和云端隐私基本上就等于裸奔了。

04 官方修复与我们的避坑指南

好在 Unit 42 在 2026 年 3 月发现后，就通过谷歌的漏洞奖励计划（VRP）秘密提交了。谷歌的响应也很快，分了两步走：

1. v1.144.0（治标）：

   临时在自动生成的桶名后面加了一串随机的 uuid4，让你没法轻易预测。

2. v1.148.0（治本）：

   彻底重构了 Model.upload() 的底层逻辑，强制加入了存储桶所有权校验（Bucket Ownership Verification）。就算名字撞了，不是你的桶，SDK 也会直接报错拒绝。

由于这个漏洞的逻辑完全跑在客户端的 SDK 里，所以光看服务端是没用的。

老铁们，赶紧对照下面两步自查防御：

1. 升级、升级、还是升级！ 把你们项目里所有用到 google-cloud-aiplatform 的地方全部升到 1.148.0 或更高版本。 特别提醒： 别光看生产环境，研发手里的 Jupyter Notebook、CI/CD 自动化流水线、训练 Pipeline 才是最容易被遗忘的死角！

2. 显式指定存储桶，别偷懒！ 在写代码时，千万别再依赖 SDK 的默认行为了。一定要显式地指定一个你自己完全控制的、安全的 GCS 路径：

# 错误示范：依赖默认生成，容易被占坑
# aiplatform.Model.upload(display_name="my_model", artifact_uri="...")

# 正确示范：显式指定你控制的 staging_bucket
aiplatform.Model.upload(
    display_name="my_model",
    artifact_uri="...",
    staging_bucket="gs://your-secure-owned-bucket"
)

写在最后

其实这已经是 Vertex AI 今年第二起因为“可预测存储桶名字”翻车的安全事件了（上一个是2月份修的 CVE-2026-2473）。

有时候，很多高大上的 AI 安全问题，底层往往都是由于“自动命名、权限没校验、反序列化”这些传统安全的经典老坑导致的。开发的时候贪图一时爽，运维和安全可就要两行泪了。

大伙儿回去赶紧查查自己的代码，别让自己的心血模型半路被人给“截胡”了！

如果你觉得这篇文章对你有帮助，别忘了点赞、关注、分享三连一条龙，我们下期技术硬核盘点再见！

免责声明：

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

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

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

本文转载自：技术修道场 Hankzheng Hankzheng《代码执行+模型被盗！盘点谷歌云Vertex AI存储桶抢注Bug的底层前沿姿势》