Grok Build 被指将完整 Git 仓库上传至 xAI 存储桶,而非仅上传其读取的文件

导语：xAI 旗下的 Grok Build 编程命令行工具被发现会将整个 Git 仓库及其完整提交历史一并上传至 xAI 运营的 Google Cloud Storage 存储桶。研究人员 cereblab 在测试 0.2.93 版本时通过拦截请求克隆出 git bundle,成功恢复了一个被明确告知不要打开的 canary 文件。

xAI 旗下的 Grok Build 编程命令行工具(CLI)被发现会将整个 Git 仓库,包括完整提交历史,一并上传到由 xAI 运营的 Google Cloud Storage 存储桶中,而不仅仅是某次编码任务实际需要的文件。研究人员 cereblab 在测试 0.2.93 版本时,捕获了其中一次上传,从未经加密通道发出的拦截请求中克隆出 git bundle,并成功取回了一个被明确告知不得打开的文件。

上传流量走的是与模型调用本身不同的通道,字节量对比一目了然。在一个模型从未读取的 12 GB 仓库中,发往 `/v1/responses` 的模型轮次(model-turn)流量约为 192 KB,而发往 `/v1/storage` 的存储通道流量则达到 5.10 GiB,模型所需数据与离开本机的数据之间相差约 27,800 倍。

存储上传以 73 个分块的形式进行,每个分块约 75 MB,响应全部返回 HTTP 200。在研究人员进行的体积扫描中,上传总量与仓库总体大小保持线性关系。目标存储桶名为 `grok-code-session-traces`,该名称既出现在二进制文件中,也出现在一个分阶段上传的 `metadata.json` 中,而该文件的逐文件路径均指向 `gs://grok-code-session-traces/`。

未读取文件验证:研究人员预先植入 `src/_probe/never_read_canary.txt`,并写入唯一的标记字符串。克隆捕获到的 bundle 后,该文件被原样恢复,连同仓库的完整提交历史一起被还原;同一测试在另一个不相关的仓库上得到重复验证。这些捕获所证明的是数据的传输、接收与存储,而不是用于训练。

研究人员并未声称 xAI 拿这些代码进行了训练,也未声称其员工阅读过这些内容,更未声称所有被 `.gitignore` 忽略的文件都会被一并打包上传。从网络流量来看,被追踪的文件及其历史就是被一并外传的。

机密凭据的泄露路径是另一条,且更为直接。当 Grok 读取文件时,其内容会进入模型轮次,而一个被追踪的 `.env` 文件随之以未脱敏的形式送出,其中包含 canary 字符串 `API_KEY` 与 `DB_PASSWORD`。同样的内容也被打包进一个准备发往存储的 `session_state` 归档中。本次测试植入的均为假凭据,因此未发生真实泄露。但问题本身仍然存在:代理在任务过程中读取的凭据文件被原样外传并被存储,且未做任何脱敏处理。

开发者最常想到的那一项设置在这里并未发挥作用。即使关闭了 "Improve the model"(改进模型)选项,Grok 仍然会上传仓库;同时服务端的 `/v1/settings` 响应也持续返回 `trace_upload_enabled: true`。该开关控制的是数据是否用于模型训练,而并不控制代码是否离开本机。两者是两套不同的控制项,而其中只有一项暴露给了用户。

每一款云端编程代理都必须将一部分源码发送至远端模型才能工作,因此第一条通道是合理的。而上传整个被追踪的仓库及其历史,所跨越的边界要远大于仅发送任务所需文件。

一个仓库可能包含专有代码、内部 URL、客户数据,以及已经从工作目录中移除、但仍残留在提交历史中的凭据。在 cereblab 自身进行的跨工具对比中,Claude Code 与 Codex 都没有发送仓库 bundle;Gemini 在空闲测试中也没有发送,不过其实景任务运行因配额限制在完成前就被中止。Grok Build 是其中的异常值。但这并不意味着它们是 "本地化" 工具——所有这些云端代理都会发送它们打开的文件,而对整个工作区进行的批量收集是 Grok Build 所特有的行为。

7 月 13 日,同样的 0.2.93 二进制停止了存储请求。cereblab 重新测试了 6 次,均未观察到 `/v1/storage` 上传,服务端此次返回的是 `disable_codebase_upload: true` 与 `trace_upload_enabled: false`。开发者 Peter Dedene 报告其账户下也返回了相同的标志位,因此这一关停并非仅在 cereblab 单一机器上的观察结果。被测试的客户端仍停留在 0.2.93 版本,变化的却是服务端配置,说明这是一次服务端开关切换,而非通过更新发布的修复。xAI 尚未确认该变更是否覆盖所有账户,也未确认其是否为永久性措施。

截至目前,xAI 是在 X 平台上对该事件作出回应,而非通过安全公告或更新日志说明。@SpaceXAI 账号表示,采用零数据保留(zero data retention)的企业团队的代码或追踪数据从不会被存储;API 密钥的使用尊重 ZDR 设置;未启用该设置的个人消费者可以在 CLI 中运行 `/privacy` 来禁用保留,并删除此前同步过的数据。

对于已经使用过该工具的用户而言,正确的做法并不是等待 xAI。应当轮换 Grok 可能已经外传的任何凭据:它读取过的任何文件、被追踪文件中的内容,以及 bundle 中携带的 git 历史中包含的任何凭据——包括那些曾经提交过、之后又被删除的机密。

被 `.gitignore` 忽略且从未提交的文件确实没有进入 bundle;而一旦被提交的文件,则会随历史一同外传,即便之后再将其删除也无法追回。一项针对 0.2.99 版本的独立分析发现,上传代码仍存在于二进制文件内,只是被服务端标志所抑制,因此 xAI 完全可以在不发布更新的情况下重新开启该功能。

xAI 至今仍未解释为何默认情况下会上传完整仓库、数据被保留多长时间,以及影响了多少用户。训练用数据的选择退出(opt-out)并不等于你的代码会留在本机——离开本机的内容,值得由你自己来核实。

来源信息

来源：The Hacker News

原文链接：https://thehackernews.com/2026/07/grok-build-uploads-entire-git.html

作者：info@thehackernews.com (The Hacker News)