powered by TechFeed
表示モード
Deep Dive

クリーンなGitHubリポジトリがAIコーディングエージェントをマルウェア実行に誘導 — コードに悪意のある記述は一切なし、エラー修正の自律動作そのものが攻撃経路に

6月27日、BleepingComputerが「Clean GitHub repo tricks AI coding agents into running malware」と題した記事を公開した。この記事では、一見クリーンなGitHubリポジトリを使ってAIコーディングエージェントにマルウェアを実行させる新たな攻撃手法について詳しく紹介されている。

6月27日、BleepingComputerが「Clean GitHub repo tricks AI coding agents into running malware」と題した記事を公開した。この記事では、一見クリーンなGitHubリポジトリを使ってAIコーディングエージェントにマルウェアを実行させる新たな攻撃手法について詳しく紹介されている。


リポジトリ自体にはマルコードがない、という点が核心

Mozillaのセキュリティ研究部門であるZero Day Investigative Network(0DIN)が公表したこの攻撃手法の最大のポイントは、クローンしたリポジトリのコードに悪意のある記述が一切含まれないという点だ。セキュリティツールによるスキャンも、人間によるコードレビューも、どちらも問題を検出できない。

攻撃が成立するのは3つの要素の組み合わせによる:

  1. 見た目が普通のGitHubリポジトリpip3 install -r requirements.txtpython3 -m axiom init といった標準的なセットアップ手順が書かれているだけだ。
  2. インストールされるPythonパッケージが意図的に初期化前はエラーを返す仕様になっている。ここで重要なのは、axiom は攻撃者が用意した正規パッケージと同名の偽パッケージであるという点だ。エラーメッセージは「python3 -m axiom init を実行してください」と指示する。Claude Codeはこれを通常のセットアップエラーと判断し、自動でそのコマンドを実行しようとする。
  3. python3 -m axiom init の実行がシェルスクリプトを呼び出す。そのスクリプトは攻撃者が制御するDNS TXTレコードから設定値を取得し、それをコマンドとして実行する。

0DINの研究者はブログ記事でこの仕組みを次のように説明している:

「Claude Codeはシェルを開くことを決定したのではない。エラーを修正しようとしただけだ。リバースシェルは、Claude Codeが実際に評価したものから3段階の間接処理を経た先にある。信頼したエラーメッセージ、値を取得するスクリプト、そして一度も見ることのないDNSレコード。」

この「3段階の間接処理」こそが、静的解析や人力レビューによる検出を困難にしている核心だ。コードを読んでも、パッケージのソースを追っても、最終的に何が実行されるかは実行時まで判明しない。


エージェントが「攻撃チェーン全体を自動化」してしまう

この手法の厄介さは、AIエージェントの「自律的にエラーを修正しようとする」という通常の動作そのものが攻撃に利用される点にある。Claude Codeはエラーが出れば次の手を自動で試みる。その「次の手」が攻撃者の用意したコマンド実行につながる。

類似の攻撃ベクターとしては、プロンプトインジェクションサプライチェーン攻撃が知られているが、今回の手法はいずれとも異なる。悪意のある命令をコードやプロンプトに直接埋め込むのではなく、エージェントの「エラー修正」という正常な推論プロセスを起点として攻撃チェーンを起動させる点が新しい。AIコーディングエージェントが広く普及するにつれ、Cursor、GitHub Copilot Workspace、Devinなど類似のエージェント製品も同様の攻撃面を抱えうると考えられる。

攻撃が成功した場合、攻撃者は開発者の権限でインタラクティブシェルを取得することになる。環境変数、APIキー、ローカル設定ファイルへのアクセスに加え、永続化の足がかりにもなりうる。

なお、現時点ではこの攻撃手法はコンセプト実証(PoC)の段階だ。しかし0DINは、偽の求人票、チュートリアル、ブログ記事、ダイレクトメッセージなどを通じて、こうした悪意あるリポジトリが容易に拡散しうると警告している。開発者が「面白そうなOSSを試す」「技術ブログのサンプルコードを動かす」という日常的な行動がそのまま攻撃ベクターになる。


対策として求められるもの

0DINは対策として、AIエージェントがセットアップコマンドの実行チェーン全体を開示することを推奨している。動的にフェッチされるスクリプトやコードも含め、何が実行されるかを透明にすべきという立場だ。

開発・運用の現場でとりうる具体的な対策としては、以下のような方向性が考えられる:

  • サンドボックス実行の徹底:AIエージェントによるパッケージインストールやセットアップは、ホスト環境から隔離されたコンテナやDevContainer内で行う
  • ネットワークアクセスの制限:セットアップ実行時に外部DNS・外部ホストへのアウトバウンド通信を制限し、不審なDNSクエリを検出できる環境を整える
  • 実行前確認ステップの設計:エージェントが自律的に実行するコマンドのうち、initsetup など初期化系のものは人間の承認を必須とするポリシーをエージェントのシステムプロンプトレベルで設定する
  • 依存パッケージの事前検証requirements.txt に列挙されたパッケージをpip-auditなどのツールで事前スキャンし、既知の偽パッケージや typosquatting を検出する

AIコーディングエージェントは、エラー修正やセットアップの自動化という点で開発者の作業を効率化する。一方でその自律性が、今回のような「エラーを直そうとしたら攻撃に加担していた」という状況を生む。エージェントに任せる操作の範囲と、実行前の確認ステップをどう設計するかは、AIエージェントが開発フローに深く組み込まれていく中で、ツールベンダー・開発チーム双方が継続的に向き合うべき課題となっている。

詳細はClean GitHub repo tricks AI coding agents into running malwareを参照していただきたい。