needhelp
← 返回博客

Grok Build CLI 偷偷上传了你的整个仓库——包括 .env 密钥

作者 needhelp
Security
AI Agent
隐私
xAI

研究者 cereblab 发现，xAI 的 Grok Build CLI（0.2.93 版）会在用户不知情的情况下，把整个 git 仓库——密钥、完整提交历史，全都在内——复制到一个 Google Cloud Storage 存储桶里。

发生了什么

这个工具会发出两类对外请求。模型对话走 POST /v1/responses。但另一个 POST /v1/storage 请求会把整个工作区加上完整的 .git 历史打包，发往 gs://grok-code-session-traces。

这个存储桶归 xAI 所有。上传只是“使用这个 CLI”的副作用——没有导出按钮，没有提示，也没有任何警告。

数据量让人头皮发麻。在一个 12 GB 的测试仓库上，模型一行代码都没读，/v1/responses 传输了约 192 KB。而 /v1/storage 传了 5.10 GiB，拆成 73 个包。27,800 倍 的差距。模型用了 192 KB 的上下文；xAI 的服务器拿到了你的整个仓库。

金丝雀测试

cereblab 埋了一个叫 never_read_canary.txt 的文件，里面塞了一个唯一字符串。提示词就一句话——“请只回复：OK。不要读取或打开任何文件。“模型确实只回了 OK。但上传的数据包里，那个金丝雀字符串赫然在列。

这说明上传并不是模型按需读文件触发的，而是一个无论你问什么都会执行的固定流水线。

为什么“退出”没用

Grok CLI 里有个“改进模型”的开关。关掉它，理应停止把你的数据用于训练。但 cereblab 的抓包显示，服务端仍然返回 trace_upload_enabled: true 和 upload_enabled: true，上传照样发生。

CLI 有个 --deny 参数，用来限制模型能读哪些文件。它只拦读取。对网络出口毫无作用——打包好的数据已经发出去了。

那份 gist 说得很直白：“选择退出，并不能阻止你的仓库离开这台机器。”

跨工具泄漏

抓包显示这个工具还顺手扫走了 ~/.claude/ 下的文件。那是另一款产品的配置目录。与之无关的服务密钥——cereblab 举了一个百度 Miaoda 的 API key——也跟着仓库一起离开了机器。

另一位复现了该发现的研究者，在自己的日志里找到了 339 次自动上传。其中一次上传的对象，是整个用户主目录——SSH 密钥、密码管理器数据、浏览器配置，什么都在里面。

远程开关

7 月 12 日，事件开始发酵。这时发生了一件事，xAI 没有公开说过：同一个客户端二进制文件、同一个 SHA-256 哈希值，突然开始收到不同的服务端响应。

disable_codebase_upload: true。trace_upload_enabled: false。

上传停了。不需要客户端更新。没有 changelog。没有通知。

这意味着 xAI 一直有能力在任何时候、对任何 Grok CLI 安装、远程开启或关闭数据收集，而用户完全不知情。他们只是选择默认开启，且从不提起。

Musk 回应

7 月 14 日，Elon Musk 在 X 上对争议做出了回应，就一个字：“True”（属实）。接着他说：

“作为预防措施，此前上传至 SpaceXAI 的所有用户数据将被完全且彻底删除。一个字节都不会留下。”

同一天，xAI 给 Grok CLI 上线了 /privacy 命令：

  • /privacy —— 查看当前数据留存状态
  • /privacy opt-out —— 关闭数据留存，并追溯删除已同步的数据

Grok Build 负责人 Andrew Milich 确认，更改隐私设置会触发对已同步云端数据的追溯删除。企业客户可启用“零数据留存”（ZDR）模式。

但有几个问题始终没人回答：没有发布安全公告。没有解释为什么要在未经同意的情况下收集整个仓库。没有独立审计来验证删除是否真的执行了。v0.2.98 的 changelog 对仓库上传这件事只字未提。

怎么判断自己是否中招

  • 在 MITM 代理后面跑 CLI：HTTPS_PROXY=http://127.0.0.1:8080，盯住发往 grok-code-session-traces 存储桶的 POST /v1/storage。
  • 在二进制文件 / 字符串里搜写死的存储桶名 grok-code-session-traces。
  • cereblab 的复现仓库里带了一个 verify.sh，能把返回的数据包重新下载解包，让你看清到底传走了什么。
  • 检查出口流量日志，看任何 Grok CLI 会话期间有没有连 Google Cloud Storage。
  • 在 Grok CLI 里跑 /privacy 看当前数据留存状态。
  • 另一位研究者通过自查日志发现了 339 次上传——如果你用过这个工具，就当你的仓库已经离开这台机器了。

该怎么做

  • 立刻执行 /privacy opt-out，停止后续数据留存并请求删除已上传数据。
  • 直接卸载受影响的 0.2.93 版本。
  • 在网络层拦掉到 Google Cloud Storage 的出口——防火墙规则或 Clash 的 reject 规则：(PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com)。
  • 如果必须继续用，往 ~/.grok/config.toml 里加： 
    [harness] disable_codebase_upload = true
    [features] telemetry = false
    [telemetry] trace_upload = false
  • 轮换你用这个版本打开过的任何仓库里的所有凭据。.env 文件常常被误提交，或者就躺在工作区里；.gitignore 救不了你——打包数据不带感情，跟踪到的文件一概卷走。把一切都当作已泄露来处理。

数据可以删。信任，没那么容易重建。

参考

分享本页