needhelp
← ブログに戻る

Grok Build CLI があなたのリポジトリ全体をこっそりアップロードしていた — .env ファイルも含めて

著者 needhelp
Security
AI Agent
プライバシー
xAI

cereblab という名の研究者が、xAI の Grok Build CLI（バージョン 0.2.93）が、ユーザーに知らせることなく、git リポジトリ全体 — シークレット、完全な履歴、すべて — を Google Cloud Storage のバケットにコピーしていたことを突き止めました。

何が起きたか

このツールは 2 種類の外部リクエストを発行していました。モデルへの入力は 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 というファイルに一意の文字列を埋め込みました。プロンプトは文字通り “Reply with exactly: OK. Do not read or open any files.” でした。モデルはその文字通りに応答しました。それでも、アップロードされたバンドルからカナリア文字列が回収されました。

つまり、この持ち出しは、モデルがその場でファイルを読んだことに駆動されたものではありません。何を頼んだかに関わらず必ず実行される組み込みのパイプラインでした。

オプトアウトが効かなかった理由

「モデルを改善する」という設定があります。これをオフにすれば、自分のデータが学習に使われるのを止められるはずです。しかし cereblab のキャプチャでは、サーバーは依然として trace_upload_enabled: true と upload_enabled: true を返していました。アップロードは止まりませんでした。

CLI には、モデルが読めるファイルを制限する --deny フラグがあります。しかしそれがブロックするのは読み取りだけです。ネットワークへの出口（egress）には何の影響もなく、バンドルはすでに外へ送られていました。

gist はこの結論を率直に述べています。“Opting out does not stop your repository from leaving the machine.”（オプトアウトしても、リポジトリがマシンから持ち出されるのを止めることはできない。）

ツールをまたいだ漏洩

キャプチャによると、このツールは ~/.claude/ 配下のファイルも巻き込んでいました。ここは別の製品の設定ディレクトリです。無関係なサービスのキー — cereblab は Baidu Miaoda の API キーを挙げている — が、あなたのリポジトリと一緒にマシンを出て行きました。

この発見を再現した別の研究者は、自身のログから 339 回の自動アップロード を確認しました。そのうち 1 回のアップロードにはホームディレクトリ全体が含まれており — SSH キー、パスワードマネージャーのデータ、ブラウザのプロファイル、すべてが対象になり得ました。

リモート・キルスイッチ

7 月 12 日、この話が拡散する中で、xAI が一切公表しなかったある事態が発生しました。同じクライアントバイナリ、同じ SHA-256 ハッシュのまま、突然サーバーからのレスポンスが変わり始めたのです。

disable_codebase_upload: true。trace_upload_enabled: false。

アップロードが停止しました。クライアントの更新なし。チェンジログなし。通知なし。

これは、xAI が常に、あらゆる Grok CLI インストールに対して、いつでも、ユーザーに知られることなくデータ収集をリモートで有効化・無効化できたことを意味します。彼らはそれをデフォルトでオンにし、一度も言及しなかっただけです。

Musk の応答

7 月 14 日、Elon Musk はこの騒動に対して、たった一言で応答しました。“True”（事実だ）。その後の投稿：

“予防措置として、これまでに SpaceXAI にアップロードされたすべてのユーザーデータを完全かつ徹底的に削除する。文字通り何ひとつ残らない。”

xAI は同時に Grok CLI 向けの /privacy コマンドを発表しました：

  • /privacy — 現在のデータ保持状態を表示
  • /privacy opt-out — データ保持を無効化し、既に同期されたデータの遡及的削除を実行

Grok Build 責任者の Andrew Milich は、プライバシー設定の変更が既存のクラウドデータの遡及的削除をトリガーすると確認しました。エンタープライズ顧客には「ゼロデータ保持（ZDR）」モードも提供されます。

しかし変わっていないこともあります。セキュリティアドバイザリは出ていません。なぜ同意なくリポジトリ全体が収集されたのか、説明はありません。削除に対する独立した監査もありません。v0.2.98 のチェンジログには、リポジトリアップロードに関する記載がまったくありませんでした。

影響を受けたか確認するには

  • 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 宛のトラフィックがないか、出口の egress ログを確認する。
  • Grok CLI で /privacy を実行し、現在のデータ保持状態を確認する。
  • 別の研究者は自身のログ確認で 339 回のアップロードを発見している — 一度でも使ったなら、リポジトリは流出したと考えるべきだ。

すべきこと

  • ただちに /privacy opt-out を実行し、今後のデータ保持を停止し、既にアップロードされたデータの削除を要求する。
  • 影響を受けたバージョン（0.2.93）を完全にアンインストールする。
  • ネットワーク層で Google Cloud Storage への出口を遮断する — ファイアウォールのルールや Clash の拒否ルール：(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 では守れない — バンドルは追跡ファイルを問わず運んでいたのだ。すべてを侵害済みと見なせ。

データは消せる。信頼は、そう簡単にはいかない。

参考文献

このページをシェア