刚火了两天，马斯克的Grok CLI就被曝「偷家」

--> 本頁主題: 刚火了两天，马斯克的Grok CLI就被曝「偷家」

少年晴天

級別：精靈王 ( 12 )
發帖：599
威望：3532 點
金錢：13505 USD
貢獻：25000 點
註冊：2011-06-06

xAI的Grok CLI正在遭遇一场严肃的信任危机。
昨晚，开发者@cereblab针对xAI推出的官方开发命令行工具Grok Build CLI（版本 0.2.93）进行了一次详尽的网络底层抓包分析。

结果令人心惊：在默认配置下，该工具会绕开模型的正常对话通道，在后台将用户的整个代码仓库打包并静默上传至云端。
Grok CLI 是如何传输数据的？
任何云端AI编码工具都需要接收代码上下文来生成回复，这无可厚非。
但xAI内部构建了一套生产级的、完全独立的隐蔽上传管线。
这套管线通过两个通道，源源不断地向xAI服务器输送用户数据。

通道A：模型对话流（明文无脱敏）
当 Grok 读取用户的 .env、配置文件或密钥文件时，它会将这些内容毫无遮拦、不经任何脱敏地序列化进 POST /v1/responses 的请求体中。测试中，.env 文件里的 API_KEY 和 DB_PASSWORD 均以明文形式被发送和存档。

竞争对手的数据也不放过

更让开发者群体感到不安的是，Grok CLI 的收集逻辑似乎缺乏清晰的“边界感”。

由于该工具在启动时会尝试兼容和接管其他开发环境（例如竞争对手 Anthropic 的 Claude Code），其扫描范围会延伸至项目目录之外。多方实测表明，Grok在运行过程中会主动读取并打包系统全局环境下的敏感配置：

用户根目录下的 ~/.claude.json 配置文件；
全局的 AGENTS 规则与数十个本地 Skill 脚本。
因为其后台收集器的逻辑是“只要运行中读取过，就无条件打包上传”，导致这些本属于其他工具的私密配置文件，被作为 supplemental_file（补充文件）一起送上了 xAI 的云端。

部分开发者配置在其中的第三方API密钥，也因此在不知情的情况下发生了泄露。

xAI悄悄拉闸

在这个机制被安全社区曝光后，xAI的反应很微妙。

@cereblab对比了7月10日至13日前后的服务器响应数据：

在最初曝光时，客户端接收到的配置为 trace_upload_enabled: true。
然而，随着社区讨论发酵，在客户端版本（二进制哈希值）未做任何更新的情况下，xAI 的服务器响应中突然新增了 disable_codebase_upload: true 字段，且将 trace 上传强行设为了 false。
这种“无需更新客户端，通过云端配置远程关闸”的操作，虽然暂时阻断了默认上传，但也恰恰证明了两个事实：

1.xAI 拥有对本地客户端行为的绝对远程控制权。

2.此前备受争议的“Improve the model / 改进模型”前端开关，在技术层面上并不能阻止后台的数据收集。

即使关闭了该选项，底层的上传管线依然会根据服务器的指令自行运转。

截至目前，xAI官方尚未发表声明。
事件发酵后，热门开源项目CC Switch的开发者也表示，由于Grok的安全问题，cc switch对Grok的相关支持功能会暂缓发布。

无论最终调查结果如何，这件事都再次提醒开发者一个现实问题。
当AI拥有近乎无限的系统权限、且缺乏透明度时，下游的开源生态将不得不为这种“信任赤字”买单。

DMCA / ABUSE REPORT | TOP Posted: 07-13 20:42 樓主引用 | 發表評論

蒋光头太可恨

級別：騎士 ( 10 )
發帖：3186
威望：505 點
金錢：82153 USD
貢獻：0 點
註冊：2017-10-13

赞(3) | 資料短信推薦編輯

果然，跪舔匪党的人和匪党都是一个德行

TOP Posted: 07-13 20:44 #1樓引用 | 點評

铁甲二流子