7月13日、開発者A Green BeingがXプラットフォーム上でunified.jsonのログのスクリーンショットを投稿し、マスクが率いるxAIの開発ツールであるGrok Buildが、自身の全ユーザーのホームディレクトリをまとめてパッケージ化し、xAIのサーバーにアップロードしたと告発した。漏えいした内容には、個人のSSH鍵、パスワードマネージャーのデータベース、個人の書類、写真、動画が含まれており――「すべてが漏えいした」。
A Green Beingのログのスクリーンショット証拠
(出所:A Green Being)
A Green BeingがX上で共有したunified.jsonのログのスクリーンショットによれば、システムは確かに大量のrepo_state.upload.startリクエストをトリガーしており、アップロードパスは直接当該ユーザーのホームディレクトリ(/home/usuario)を指している。これは、Grok Buildが明確なファイルのフィルタリングや除外を行わないまま、極めて機微な情報を含むすべてのローカルファイル(SSH鍵、パスワードマネージャーのデータベース、写真、動画)をxAIのクラウドのエンドポイントにすべて送信したことを意味する。
A Green Beingは、ホームディレクトリ(Home Directory)下で不注意にもGrok Buildツールを実行したことが、このプライバシー被害を引き起こしたと述べている。CyberSatoshiはこれに対して「君のほうがまだ惨いよ。君は自分のホームディレクトリでGrokを直接動かしたんだ」と返信した。
セキュリティ推奨:ホームディレクトリで絶対に実行しない。Sandboxと監視ログの指示を使用する
セキュリティ専門家の提案に基づき、Grok Buildなどの類似のAI支援開発ツールをすでに利用している、または利用を検討している開発者は、以下の防護措置を講じるべきだ。
· ホームディレクトリまたはルートディレクトリで、この種のAIツールを絶対に実行しない
· 隔離環境を使用:独立した仮想環境(Sandbox)、Dockerコンテナ、または専用の制限付きユーザーアカウントで実行する
· 監視ログを積極的に行う:ターミナルの指示(cat ~/.grok/logs/unified.json | grep repo_state.upload)で異常なデータアップロード動作がないか確認する
· 直ちに履歴ログを確認する:すでにGrok Buildを使用している場合は、ローカルのGrokログファイルを直ちに参照し、データ漏えいがないか確認する
よくある質問
Grok Buildはなぜプロジェクトのコードだけでなく、ホームディレクトリ全体をアップロードするのか?
報道によれば、Grok Buildはバックグラウンドでアップロード操作を実行する際、適切なファイル除外の仕組みが欠けている(自動で.gitignoreを無視する、またはシステムの隠しファイルを除外するなど)。ユーザーがホームディレクトリ下でツールを実行すると、ツールの設計上、ホームディレクトリが「全体のコンテキスト環境」として扱われ、コードファイルだけに限定されず、すべてがアップロードされるのだ。これは、ツールの設計上の欠陥と、ユーザーが不適切な場所でツールを使ったという二重の失敗である。
CyberSatoshiは以前、具体的にどのようなリスクを指摘していたのか?
報道によれば、CyberSatoshi(@XBToshi)は以前、Grok Buildがバックグラウンドで黙って、プロジェクトリポジトリ(Repository)全体、Gitの履歴、さらにAPI鍵などの機密情報を含む.envという隠しファイルを含めて、すべてをGoogleクラウドプラットフォーム(GCP)にアップロードする、と警告していた。また、これは今後のモデル学習に悪用される可能性が非常に高いと指摘し、当時すでに開発者に対してローカルのGrokログファイルを直ちに確認するよう呼びかけていた。
自分のPCにGrok Buildによってデータがすでにアップロードされているかを、今すぐ確認するには?
報道によれば、次のターミナルの指示でログを確認できる:cat ~/.grok/logs/unified.json | grep repo_state.upload。ログ内にrepo_state.upload.startの大量の記録があり、アップロードパスがホームディレクトリまたはルートディレクトリを指している場合、データがクラウドに送信済みであることを示す。Grok Buildの利用は直ちに隔離されていない環境で停止し、関連する機微情報(SSH鍵、API鍵)を今すぐ置き換える必要があるかを評価することを推奨する。