如果有个AI助手，嘴上说只帮你检查一个文件，背地里却把你的整个仓库打包上传到云端——包括你没有分享的提交历史、内部文档，甚至写着数据库密码的 .env 文件，你会怎么想？安全研究员 Cereblab 近期对 xAI 的 Grok Build CLI 进行了一次线路级分析，发现版本 0.2.93 确实就是这么干的。而且，即使你明确要求它“不要读任何一个文件”，它依然会把仓库快照推送到谷歌云上。
这个发现不是靠猜测，而是通过代理抓包，在一个精心布置的测试仓库里完成的。仓库里塞了假的金丝雀凭证，用来追踪数据到底有没有被传出去。结果，从 .env 里捞出来的假 API 密钥和数据库密码，同时出现在了两个地方：一个是模型请求通道的 POST /v1/responses 记录里，另一个是通过 POST /v1/storage 发送的会话状态存档中。换句话说，不管 Grok Build 是跟模型聊天，还是做后台状态同步，你的密钥都被它一五一十地“朗读”了出去。
更让人心里发毛的是，上传机制根本不是“手滑”就能解释的。研究发现，Grok Build 会单独拉出一套后台上传逻辑，把你整个 Git 仓库打包成一个 bundle 传走，而不只是拷贝当前任务需要的几个文件。那个被捕获的 Git bundle 里，不但有代码本身，还有完整的提交历史，以及一个研究员明确指示“不准读”的文件。也就是说，你在本地 git commit 里留下的所有痕迹——包括你可能已经删掉、或者压根没想暴露的历史私密信息——都成了这趟“云上之旅”的附带行李。
Cereblab 做了一个很极端的实验：他用一句话提示 Grok Build：“Reply with exactly: OK. Do not read or open any files.” 也就是明令禁止它碰任何文件。结果抓到的网络流量里，照样出现了被植入的金丝雀标记文件。这说明仓库上传机制完全独立于模型交互时的文件访问，它像个自动备份脚本，在后台默默运行，压根不管你在前台说了什么。
为了测量这个“暗通道”到底有多能吃，研究员搞了一个 12GB 的仓库，里面塞满了随机文件。在抓包停止前，模型通道 POST /v1/responses 只传了大约 192KB 的数据——这还算合理，毕竟只是对话需要的载荷。但存储通道那边就夸张了：至少传走了 5.10GiB 的数据，由 73 个上传块组成，每个块约 75MB，而且全部返回了 HTTP 200 状态码，说明服务器欣然接收了这些数据。目的地很清楚：谷歌云存储的一个 Bucket，叫做 grok-code-session-traces。从 Grok 二进制文件里提取的字符串、中间元数据中指向 gs://grok-code-session-traces/ 的引用，以及实际观察到的上传行为，都证实了这一点。
对开发者来说，这意味着几重风险同时敞开了口子。首先，任何托管在本地并有 Git 历史的专有源代码，都可能被完整发出。其次，部署文件、内部文档、历史凭证等原本依赖 .gitignore 或仅仅靠“别主动打开”来保护的敏感内容，现在因为整个仓库快照而上云。即便你从不手动打开 .env，哪怕只是让 Grok Build 处理一个无关的代码片段，它照样会读到你的仓库元数据，并把 .env 里的内容连同那 73 块 Upload 一起送
热门跟贴