xAI Grok CLI Exposed Developer Code Through Automatic Whole-Repository Uploads
2026/07/14 gbhackers — xAI の Grok Build CLI バージョン 0.2.93 のデフォルト設定に対する再現可能なワイヤレベル分析により、未追跡のファイルおよびコミット履歴を含む Git リポジトリ全体が、xAI のインフラへ送信されていたことが判明した。この挙動により、エージェントがアクセスしたファイルの内容も、編集や秘匿化が行われることなく送信されており、その中には模擬認証情報を含むテスト用の “.env” ファイルも含まれていたと、研究者たちは指摘している。
独立研究者 cereblab は、制御された HTTPS インターセプト・プロキシ経由で CLI をルーティングし、macOS 上で Grok Build のトラフィックを調査した。この分析で使用されたのは、実際のシークレットではなく、一意に識別可能なカナリア文字列を取り込んだ使い捨てリポジトリである。それにより、リクエストのホスト名／パス／サイズ／レスポンスコード／リクエスト・ボディなどが取得された。
xAI Grok CLI が開発者コードを露出
最も深刻な発見は、別個のリポジトリ・アップロード・チャネルが使用されていたことである。ファイルへアクセスせずに “OK” とだけ応答するよう、Grok に対して明示的に指示したテストで研究者たちは、CLI が POST “/v1/storage” 経由で Git bundle をアップロードしたと報告している。取得されたバンドルをクローンしたところ、アクセスされていないカナリア・ファイルとリポジトリの完全な Git 履歴が明らかになった。
このテストは、別の無関係なコードベースでも再現されたと報告されている。通常において、クラウド・コーディング・エージェントは、推論に必要なファイルのみを送信するため、この挙動はきわめて重要である。エージェントによるファイル・アクセスとは独立したかたちで、追跡対象のすべてのコンテンツ／履歴がアップロードされることで、機密情報が露出するリスクが大幅に高められる。
一度もアクセスされていないランダムなコンテンツを含む、12 GB のリポジトリを用いたスケール・テストでは、キャプチャが手動で停止されるまでの間に、”/v1/storage” 経由で少なくとも 5.10 GiB が約 75 MB ごとの 73 チャンクに分割されて転送されたことが記録された。
記録されたすべてのストレージ・アップロードは、HTTP ステータス 200 を返した。その一方で、同一セッション中のモデル応答トラフィックはわずか 192 KB にとどまり、約 27,800 倍もの差が確認された。
分析の結果、Grok がファイルへアクセスした際に、その内容が “/v1/responses” へのリクエストに含まれることも判明した。偽の API キーとデータベース・パスワードのカナリアを含むテスト用 “.env” ファイルが、モデルへのリクエスト・ボディとストレージ・アップロード用にステージングされた、両方のセッション状態のアーカイブで確認された。
研究者たちは、重要な制限事項も強調している。このテストでは、使用した特定のカナリア値が編集や秘匿化を行わずに送信されたことが確認されたが、あらゆるシークレット秘匿化メカニズムが存在しないことまでは証明されていない。また、リポジトリ・スナップショットに、”.gitignore” で除外されたファイルが含まれていたかどうかも確認されていない。
バイナリ文字列／取得したメタデータは、grok-code-session-traces という名前の Google Cloud Storage バケットを示唆しており、ステージング済みファイル識別子は “gs://grok-code-session-traces/…” を参照していた。
この分析では、”~/.grok/upload_queue” 配下でのローカル・ステージングも確認され、大規模なアップロード時において、それにより大量のディスク容量が消費される可能性があると、研究者たちは警告している。
レポートによると、ユーザー向けの “Improve the model” オプションを無効化しても、テストで確認されたコードベースのアップロードは防止されなかった。サーバ設定レスポンスでは、”trace_upload_enabled: true” が維持されており、オプションを無効化した後も Git bundle のアップロードが継続していたという。
ただし、アップロードされたデータが、xAI モデルの学習に利用されたことを、この証拠が決定的に立証するわけではない。それが示すのは、データ送信／ストレージ・リクエストの成功／ローカル・ステージングの挙動にすぎない。
7月14日に追加された更新で cereblab は、xAI がサーバ側で “disable_codebase_upload: true” を設定し、コード・アップロード・メカニズムを無効化したと報告した。さらに、研究者たちは、xAI がプライバシーに関するオプトアウト・オプションを追加したことも明らかにしたが、これはデータ送信を防止する制御機能ではなく、データ保持設定として説明されていた。この更新では、アップロードされたデータを削除すると、以前に Elon Musk が公に約束したことにも言及しているが、その完了は依然として確認されていない。
制御されたテストリポジトリ内で、Grok Build をローカルのインターセプト・プロキシ経由で安全にルーティングするには、以下のスニペットを使用する。なお、自身が所有していないシステム／リポジトリに対しては使用してはならない。
# 別のターミナルで mitmproxy をインストールして起動するbrew install mitmproxymitmdump -p 8080# macOS で、ローカル生成された mitmproxy CA を信頼するsecurity add-trusted-cert -r trustRoot \ -k ~/Library/Keychains/login.keychain-db \ ~/.mitmproxy/mitmproxy-ca-cert.pem# テストリポジトリに対して、ローカルプロキシ経由で Grok Build を実行するHTTPS_PROXY=http://127.0.0.1:8080 \SSL_CERT_FILE=~/.mitmproxy/mitmproxy-ca-cert.pem \grok -p "Reply exactly OK. Do not read or open any files." \ --cwd /path/to/test-repository
この分析は、制御されたプロキシ設定を利用して、Grok Build CLI が送信するアウトバウンド通信を調査し、リポジトリ・アップロードの挙動を検証するものである。
このインシデントがセキュリティ・チームに示すのは、ソースコード／シークレット／ビルド・アーティファクト／Git 履歴にアクセスし得る高信頼ソフトウェアとして、AI コーディング CLI を扱うことの重要性である。
組織内の環境で、その挙動が検証されるまでは、開発者は隔離されたリポジトリを使用すべきである。さらに、追跡対象の履歴からシークレットを削除し、露出した可能性のある認証情報をローテーションした上で、AI エージェントのエンドポイントに対するアウトバウンド通信の監視を実装する必要がある。
訳者後書：今回の問題は、 CLI (Command Line Interface) がデフォルトの設定で、開発環境にある Git リポジトリ全体やコミット履歴を自動的にサーバーへ送信してしまう仕様になっていたことが原因です。 AI が必要とするファイルだけを送信するのではなく、裏側でリポジトリ丸ごとのデータをアップロードする仕組みが動いていたため、テスト用の環境変数ファイルなどの機密情報が意図せず露出してしまいました。たとえ設定画面からモデルの改善オプションを無効にしても、送信を司るサーバー側のフラグが有効なままになっていたため、データ転送を止めることができませんでした。ツールがどのように通信しているかを確認することは、自身のコードを守るためにとても大切です。
IoT OT Security News 
You must be logged in to post a comment.