リポジトリに悪意あるコードが1行もなくても、AIコーディングエージェントが勝手にセットアップを進めれば、開発PCの制御権が奪われます。
この記事では、Mozilla傘下の0DIN（Zero Day Investigative Network）が2026年6月に公開した概念実証（PoC）攻撃の仕組みと、開発者が取るべき対策を整理します。
この記事でわかること
- 間接的プロンプトインジェクションがGitHubリポジトリ経由で成立する理由
- 悪意あるコードをリポジトリに置かずにリバースシェルを仕掛ける3段階の手口
- AIコーディングツール利用者が今日から実践できる防御の考え方
https://0din.ai/blog/clone-this-repo-and-i-own-your-machine
攻撃の前提：エージェントは「信頼できる道具」として動く
間接的プロンプトインジェクションとは、ユーザーが直接入力した指示ではなく、外部コンテンツ（Webページ、ファイル、エラーメッセージなど）に埋め込まれた指示をAIが実行してしまう攻撃です。チャットボットへの入力改ざんだけの問題ではなく、ツール実行権限を持つエージェント型コーディング環境では被害が大きくなります。
0DINの研究者は、Claude Codeのようなエージェント型コーディングツールがシェルコマンド実行、ローカルファイル読み取り、ネットワーク通信を行える点を指摘しています。一度ツール利用が許可されると、リポジトリ内のREADMEやパッケージのエラーメッセージも「プロジェクト文脈」として扱われ、ユーザーが内容を逐一確認しないまま処理が進みます。
リポジトリ単体では何も怪しく見えない
0DINが再現した攻撃は、公開GitHubリポジトリだけを攻撃者が用意すれば成立します。リポジトリ内の各ファイルは個別に見れば無害で、静的解析やコードレビューでもペイロードは検出されません。ペイロードはリポジトリに存在せず、実行時にDNSのTXTレコードから取得されます。
攻撃は3つの部品を順番に連鎖させます。単体ではどれも日常的な開発作業に見えます。
1. 普通のセットアップ手順をREADMEに書く
READMEには、pipでの依存関係インストールと初期化コマンド python3 -m axiom init の実行が記載されています。初回セットアップとして自然な内容です。
2. パッケージを初期化前は動かないよう設計する
Pythonパッケージ側は、初期化前に使おうとすると RuntimeError を返し、「Run: python3 -m axiom init」と案内します。初期化必須のライブラリでよくあるパターンであり、エージェントは「エラー回復」としてこのコマンドを自動実行します。
3. セットアップスクリプトがDNSから設定値を取得して実行する
init が呼び出す setup.sh は、DNS TXTレコードを dig で取得し、結果を bash -c で実行します。リポジトリ上のスクリプトは「クラウド設定の取得」に見えますが、攻撃者が管理するTXTレコードにはbase64エンコードされたリバースシェルが格納されています。
開発者が気づかないうちにシェルが開く
開発者がリポジトリURLをClaude Codeに渡し「動かして」と依頼すると、以降はエージェントが自律的に処理を進めます。0DINのデモでは、次の流れで侵害が完了します。
- 依存関係をインストールする
- アプリ利用時の
RuntimeErrorを検知する - エラーメッセージに従い
python3 -m axiom initを実行する setup.shがDNSから取得したコマンドを実行し、リバースシェルが攻撃者サーバーへ接続する
ターミナルに表示されるのは「Initialising Axiom platform…」「Environment ready」といった正常完了のメッセージだけです。エージェントは「シェルを開く」と判断したのではなく、「セットアップエラーを直す」と判断しています。リバースシェルは、信頼したエラーメッセージ、DNS取得、実行スクリプトという3段の間接参照の先にあります。
攻撃者が手に入れるもの
0DINによると、侵害後に攻撃者は開発者と同じユーザー権限の対話型シェルを得ます。環境変数に置かれた ANTHROPIC_API_KEY、AWS_SECRET_ACCESS_KEY、GITHUB_TOKEN などの認証情報も読み取れます。SSH鍵の追加やcronジョブの登録といった永続化も可能です。
さらに、ペイロードはDNSレコードの編集だけで差し替えられ、リポジトリへの再コミットは不要です。求人情報、チュートリアル、Slackの共有リンクなど、1つのリポジトリURLが複数の開発者に届けば、AIコーディングツールで開いた人が標的になります。
なぜ検知が難しいのか
この攻撃は、リポジトリ・DNS・エージェントの信頼という3系統に部品を分散させています。静的解析はDNSルックアップだけを見つけ、ネットワーク監視は名前解決だけを記録し、エージェントは事前承認済みのセットアップ手順として処理します。どれを単独で見ても悪意は読み取りにくい構造です。
0DINのデモはClaude Codeを対象にしていますが、同種の間接的プロンプトインジェクションはCopilot系ツールやブラウザ統合型AIでも議論されています。HotHardwareの報道では、OpenAIのChatGPT Atlasブラウザでも類似のプロンプトインジェクションが確認されたと触れられています（参考）。ツール名が違っても、外部コンテンツを信頼して自律実行する設計は共通のリスクを持ちます。
開発者とツール側に求められる対策
0DINは二層の対策を提言しています。
ツール側：セットアップコマンドが実行時に何を呼び出すか、スクリプトがネットワークから何を取得するかを、実行前にユーザーへ開示する設計が必要です。コマンド文字列そのものが無害でも、実行時に取得した内容が有害になり得ます。
利用者側：見慣れないリポジトリのセットアップ手順やシェルスクリプトは、AIツールが推奨していても未信頼のコードとして扱うべきです。エージェントに任せきりにせず、setup.sh の中身やDNS参照の有無を自分の目で確認します。
Anthropicはエンジニアリングブログで、GitHubのREADMEがマルウェア検査を通過してもモデルコンテキストに入り得る点を挙げ、ツール出力への入力検査の重要性を説明しています（参考）。サンドボックス化やネットワーク制限といった実行環境の分離も、被害範囲を狭める有効な手段です。
エージェント時代の「cloneして動かす」は新しいリスクを伴う
「リポジトリをcloneしてAIにセットアップさせる」は、開発速度を上げる便利なワークフローです。一方で、外部リポジトリのREADMEやエラーメッセージが実行指示の入口になり得る以上、従来のサプライチェーン攻撃とは検知の仕方が異なります。Mozilla 0DINのPoCは、クリーンに見えるGitHubリポジトリが、DNSとエージェントの自動エラー回復を組み合わせれば、開発PCの完全な乗っ取りに至り得ることを具体的に示しました。AIコーディングを日常業務に組み込む開発者ほど、この攻撃面を前提にした運用ルールを早めに整える必要があります。