TL;DR
エクスプロイト: Manifold Security は、なりすましされた Git 作成者のメタデータが、Claude を利用したワークフローに悪意のあるコードを承認させる可能性があることを示しました。根本原因: GitHub ドキュメントには、署名されていない作成者文字列は身元が検証されていないため、信頼性の決定を行うべきではないことが示されています。重要な理由: 広範な権限を持つ GitHub Actions コーディング エージェントは、承認が人間の監視を回避する場合、同じリスクを引き継ぐ可能性があります。
今週の Manifold Security は、ワークフローが署名されていない Git 作成者のメタデータを、変更が信頼できるメンテナーからのものである証拠として処理した後、Anthropic の Claude が悪意のあるプル リクエストを承認した方法を共有しました。プル リクエストの処理を継続するために AI レビュー ボットに依存しているチームにとって、このデモンストレーションは日常的な信頼ショートカットを敵対的なコードへの直接パスに変えました。
この警告は 1 つのラボ設定を超えて届きます。同じ信頼できる開発者 ID レポートの中で、Manifold 氏は、ワークフローがプル リクエストを受け入れてマージしたこと、GitHub の検索で claude-code-action を参照するパブリック ワークフロー ファイルが 12,400 以上見つかったこと、このパターンがすでに広くコピーされていることを示唆していると述べました。
Anthropic の Claude Code GitHub Actions ドキュメントは、製品がコードを分析する実際のリポジトリ ワークフロー用に構築されていることを示しています。 GitHub イベントからのプル リクエスト、機能の実装、バグの修正。出典資料には、人為的な対応や軽減策に関する公の記述はありませんでした。
なりすましの仕組み
マニホールドのテストでは、ワークフローは著名な業界人を信頼するように設定され、その後、2 つの git config コマンドを使用して有名な AI 研究者になりすまされました。
レポートによると、その信頼ルールは、ユーザーからのプル リクエストを自動承認するのに十分なほど明示的でした。 「業界のレジェンドとして認められている。」そこから、クロード主導のレビュー フローは、偽造された作成者を正当なものとして扱い、gh pr review–approve と gh pr merge を実行するように指示され、悪意のあるプル リクエストを自動承認しました。
通常のヘルパー ファイルである悪意のある SKILL.md を偽装しました。.vscode 内の.vscode ファイルは、開発者の.env ファイルを読み取り、攻撃者が制御する Cloudflare Worker エンドポイントに送信するように設計されています。
マニホールドは、労力の少ないセットアップを次のように要約しました:
「私たちは 2 つの git config コマンドを使用して、有名な AI 研究者の ID を偽装しました。認証情報も悪用も複雑なツールもありません。Git が作成者を処理する方法の既知の機能だけです。
マニホールド セキュリティ、セキュリティ研究者 (マニホールド セキュリティ経由)
このエクスプロイトは、Git の欠陥を暴露するのではなく、リポジトリの自動化によって自己宣言された著者権限がセキュリティ制御に昇格し、AI レビュー担当者にマージ権限を与えると何が起こるかを示しました。
Git メタデータが身元証明にならない理由
マニホールドは、このインシデントは Git の脆弱性ではないと主張しました。実際のレビュー パイプラインでは、プル リクエストのボトルネックを軽減するために、メンテナは組織のメンバーシップ、過去の投稿、またはメンテナ リストを使用することがありますが、これらのショートカットでは、変更の作成者が誰であるかを証明することはできません。
GitHub のガイダンスには、未署名と記載されています。コミットには検証ステータスが含まれておらず、暗号的にチェック可能な署名の検証済みラベルと部分検証済みラベルが確保されます。また、GitHub では、管理者が保護されたブランチ上で署名付きコミットを要求できるため、署名されていない変更が信頼できる出所として渡されなくなります。
Git の署名コントロールは、コミットで宣言されている作成者文字列とは別に出所を検証するために正確に存在します。 Manifold 氏が述べているように、「それだけです。認証情報の盗難はありません。アカウントの侵害はありません。Git は、ユーザーの指示をすべて信頼します。」
メンテナーにとって、危険なショートカットはモデルの外側にあります。リポジトリ ポリシーにより、なりすまし可能な作成者文字列が ID の代わりになると、AI レビュー担当者は指示に完全に従い、不正なコードを承認できるようになります。
リスクが 1 つのクロード ワークフローを超えて拡大する理由
Manifold は、Claude Code、Copilot、Gemini CLI、Codex などの GitHub Actions のコーディング エージェントは、署名されていない作成者 ID が信頼になると同じ構造的エクスポージャを共有すると指摘しています。
Anthropic のワークフロー ガイダンスでは、手動設定ではコンテンツ、問題、プル リクエストに対する読み取りと書き込みの権限を付与できる一方、マージ前に提案を確認するようユーザーに指示できると記載されています。
GitHub の強化ガイダンスでは、より広範なポリシー リスクが明示されています。
「ワークフローやその他の自動化によるプル リクエストの作成または承認を許可すると、プル リクエストが適切にマージされない場合、セキュリティ リスクになる可能性があります。」”
GitHub ドキュメント、安全な使用に関するリファレンス (GitHub ドキュメント経由)
この警告は、リスクが機密漏洩だった昨年の GitHub Action 機密侵害の隣接報道にも当てはまります。誤ったレビュー承認ではなく、GitHub Actions の信頼への依存は同様でした。
プル リクエストの量を処理するためにすでに自動化に頼っているメンテナにとって、次のステップはすぐに実行できます。次の AI 支援マージの前に信頼ルールを監査します。署名されていない作成者文字列がまだ承認権限を持っている場合、1 つの偽造された名前によって開発者の秘密が暴露され、悪意のあるコードが共有依存関係に紛れ込み、人間のレビュー担当者が発見する前に下流のユーザーが被害を吸収したままになる可能性があります。
