GitHub Actionsの構造的欠陥「Cordyceps」が公開、MicrosoftやGoogleも無料アカウントからの攻撃対象に
2026年6月26日 17:55
ペネトレーションテスト企業のNovee Securityは2026年6月23日、GitHub ActionsのCI/CDパイプラインに潜む構造的な脆弱性パターン「Cordyceps（コルディセプス）」に関する調査結果を公開した。この脆弱性を悪用すると、無料のGitHubアカウントを持つ攻撃者が、MicrosoftやGoogleなどの大手組織のクラウド権限を奪取したり、ソフトウェアサプライチェーンを汚染したりできる可能性がある。さらに、AIコーディングエージェントがこの脆弱なパターンを学習し、新たなリポジトリに大量に複製していることも懸念されている。
■脆弱性パターン「Cordyceps」とは何か
Cordycepsは、GitHubや特定のツールにおける単一のバグではない。Novee Security（以下、Novee）は、これをGitHub ActionsのYAMLファイル内における、安全でないワークフロー構成の構造的パターンであると説明している。YAMLファイルは、開発者がプルリクエスト（PR）を作成したり、コメントを投稿したり、ブランチをプッシュしたりした際に、CI/CDパイプラインが実行すべき動作を定義する設定コードだ。
この脆弱性のメカニズムは非常に具体的である。GitHub Actionsは「pull_request_target」や「workflow_run」といったイベントトリガーをサポートしているが、これらはトリガーの契機となったフォーク元のリポジトリではなく、ベースリポジトリのコンテキストで実行される。つまり、匿名ユーザーからの信頼できないPRによってトリガーされたワークフローであっても、ベースリポジトリのシークレットやトークン、クラウド認証情報を保持したまま実行されることを意味する。
開発者が複数のワークフローを連携させ、権限の低いワークフローの出力を権限の高いワークフローに渡すような構成にしている場合、攻撃者は最初のステップを制御するだけで、データ連携を通じてチェーン内の最高権限の認証情報にアクセスできてしまう。
個々のステップ自体は正当に見え、YAMLの記述も有効で、ワークフローは指示通りに動作する。脆弱性は、誰もエンドツーエンドで監査していない信頼境界を越えて、信頼できないデータが渡される「構成」の段階でのみ発生する。GitHub自身のセキュリティドキュメントでも、これらのトリガーを信頼できないPRコンテンツとともに使用することに対して警告しており、リポジトリの侵害につながる可能性があると指摘している。
しかし、Cordycepsの調査で明らかになった不都合な真実は、Microsoft、Google、Cloudflareといった世界で最も豊富なリソースを持つエンジニアリングチームであっても、本番環境でこの誤りを大規模に犯し続けていたという点である。
■既存のセキュリティスキャナーで検出できない理由
Cordycepsの公開以来、実務担当者を最も不安にさせているのは、この脆弱性クラスが、広く普及している自動化されたセキュリティツールに対して実質的に「透明（検出不可能）」であるという点だ。
標準的な静的アプリケーションセキュリティテスト（SAST）スキャナーは、ワークフローファイルを1つずつ個別に評価する。これらはYAMLの構文を検証し、既知の危険なパターンを警告し、個々の権限設定をチェックする。しかし、ワークフローの境界を越えて推論することはできない。つまり、PRのタイトルやブランチ名、コメント本文などの信頼できない外部入力が、複数のワークフローの受け渡しを経て、高権限のクラウド認証情報に到達できるかどうかを判断することはできないのだ。
Noveeの創設エンジニアであるエラド・メゲド（Elad Meged）氏は、このギャップを次のように端的に表現している。「スキャナーに見えるのは有効なYAML構成だ。しかし、攻撃者に見えるのは、永続的なクラウド認証情報へと至る4ステップの経路だ」
この脆弱性を検出するには、信頼境界を越える攻撃者の経路全体をエンドツーエンドでシミュレートする必要がある。これは、従来の静的スキャナーや単発のペネトレーションテストが実行できるように設計されていない、高度なセキュリティ検証である。
■300以上のリポジトリで実証された脅威
Noveeは、npm、PyPI、crates.io、Goのエコシステムにわたる、影響力の大きい約3万のオープンソースリポジトリをスキャンした。1回の自動スキャンで654のリポジトリが脆弱である可能性が示され、そのうち300以上で実際に悪用可能であることが確認された。これは、無料の未認証GitHubアカウントから、コード実行、認証情報の窃取、またはサプライチェーンの侵害を達成できる状態にあったことを意味する。
確認された具体的な影響は以下の通りである。
Microsoft Azure Sentinel：PRへのコメントを投稿するだけで、MicrosoftのCIインフラ上で攻撃者のコードを実行し、期限切れのないGitHub Appキーを窃取することが可能だった。この認証情報は、顧客のSentinelワークスペースに直接配信されるセキュリティ検出コンテンツへの永続的な書き込み権限を与えるものだった。
Google AI Agent Development Kit（adk-samples）：1つのPRを送信するだけで、GoogleのCI上で攻撃者のコードを実行し、関連するGoogle Cloudプロジェクトに対する「roles/owner（オーナー）」権限（GCPで利用可能な最高権限）を攻撃者に渡すことが可能だった。
Apache Doris：2つのゼロクリック攻撃パスが確認された。1つはPRコメントを介してハードコードされたCI認証情報を流出させるもので、もう1つはactions、contents、packagesにわたる完全な書き込み権限を持つトークンを窃取するものだった。
Cloudflare Workers SDK：特別に細工されたブランチ名により、CIランナー上で任意のコマンドを実行することが可能だった。
Python Software Foundationの「Black」フォーマッター：任意のPRによってプロジェクトのボットトークンを窃取でき、PR承認の偽造や、下流で公式Dockerイメージを汚染する経路につながる可能性があった。なお、Blackは月間約1億3000万回ダウンロードされている。
Dark Readingの取材に対し、メゲド氏は攻撃の参入障壁の低さについて次のように述べている。「組織のメンバーシップや特別な権限は不要だ。無料のアカウントさえあれば、承認を偽造し、コードをプッシュし、認証情報を盗み出すことができる」
なお、影響が確認されたすべての組織は、調査結果が公表される前に脆弱性を修正している。また、公開時点で大規模に悪用された証拠は確認されていない。
■AIコーディングエージェントが脆弱性を大量複製
Cordycepsの公開において最も重大な意味を持つのは、過去に何が見つかったかではなく、現在何が生成されているかという点である。
GitHub Copilot、Cursor、Claude CodeなどのAIコーディングエージェントは現在、GitHub ActionsのYAML構成ファイルを大規模に生成している。これらは、数百万の既存のワークフローファイルを含む訓練データに対するパターンマッチングによって行われる。訓練データの中には、pull_request_targetやworkflow_runトリガーの安全でない構成（Cordycepsパターン）が広く普及しているため、AIエージェントはこれを高頻度かつ大量に再現してしまうのだ。
メゲド氏はこの動向について次のように警告している。「自律的なAIコーディングの性質上、これらのCI/CD脆弱性は永続的かつ大規模に再現され、指数関数的なスピードでリポジトリに『感染』していく。匿名ユーザーがこれを利用してソフトウェアサプライチェーンを制御できるため、私たちはこれを、世界最大級の企業のワークフローを背後から静かに操作する『人形劇（puppeteering）』のようなものだと考えている」
一度パッチを適用すれば解決する特定のCVE（共通脆弱性識別子）とは異なり、Cordycepsは構造的な構成パターンである。開発者やAIエージェントが安全でないワークフローの相互作用を記述するたびに、この脆弱性は再浮上する。そのため、対策は一回限りの突貫作業ではなく、継続的に行う必要がある。
■GitHubの対応とセキュリティチームが取るべき対策
GitHubは、PRを悪用した脆弱性（pwn-request）の広範なクラスに対して以前から対応を進めており、2026年に入ってその動きを加速させている。NoveeがCordycepsを公表する5日前の2026年6月18日、GitHubは「actions/checkout v7」をリリースした。これは、pull_request_targetワークフロー内で、レビューされていないフォークされたPRのヘッドコミットのチェックアウトを拒否することで、最も一般的な攻撃パターンをブロックするものだ。2026年7月16日には、この保護ロジックが現在サポートされているすべての主要バージョンにバックポートされる予定である。
さらに、GitHubの2026年のセキュリティロードマップには、すべての直接的および間接的なアクションの依存関係を特定のコミットSHAに固定するワークフローロックファイル、ワークフローをトリガーできるユーザーや許可されるイベントを集中管理する実行ポリシー、認証情報を宣言されたワークフローのみにバインドするスコープ付きシークレット、CI/CDランナー用のネイティブな送信ファイアウォールなどが盛り込まれている。これらの機能の多くは現在プレビュー段階であり、2026年後半に一般提供（GA）される予定だ。
ただし、2026年7月のバックポートは、最も一般的に悪用されるトリガーの特定のバリアントをブロックするだけであり、他の危険なイベント（issue_commentなど）や、actions/checkoutを使用せずに手動で信頼できないコードをプルして実行するワークフローには対応していない。セキュリティチームは、actions/checkout v7の適用を、完全な解決策ではなく、複数の対策の1つとして扱うべきである。
Noveeの主要な推奨事項は、考え方の転換である。「ワークフローコードもコードである」という認識を持ち、アプリケーションコードに適用するのと同様の厳格さでレビュー、監査、保護を行わなければならない。
具体的には、セキュリティチームはすべてのGitHub Actionsワークフローを監査し、特権コンテキスト（書き込み権限、シークレット、署名キー、パッケージ公開権限、クラウド認証情報を持つジョブ）で信頼できないPRコンテンツを処理するpull_request_targetやworkflow_runトリガーがないか確認する必要がある。また、AI支援の開発環境においては、Microsoftのセキュリティブログが提唱する「エージェントの二者ルール（Agents Rule of Two）」を適用すべきである。これは、AI駆動のワークフローにおいて、「信頼できない入力の処理」「状態を変更するツールの実行」「外部との通信」の3つの機能を同時に持たせないようにするというルールであり、これらが組み合わさることでCordycepsが悪用可能な信頼境界の条件が形成されるのを防ぐことができる。
■注目ポイントQ&A
●Cordyceps脆弱性により、特別なアクセス権なしでどのように認証情報が盗まれるのですか？
GitHub Actionsの「pull_request_target」や「workflow_run」トリガーは、信頼できない外部の投稿者によるコードやコメントから開始された場合でも、ベースリポジトリのコンテキスト（シークレットやトークンへのアクセス権を持つ状態）で実行されます。複数のワークフローが連携している場合、攻撃者が最初のステップを制御するだけで、パイプラインが持つ最高権限の認証情報を盗み出すことができます。
●なぜ既存のセキュリティスキャナーではこの欠陥を検出できないのですか？
一般的な静的アプリケーションセキュリティテスト（SAST）ツールは、ワークフローファイルを個別に評価するためです。PRのタイトルやコメント本文などの信頼できない外部入力が、複数のワークフローを渡り歩いて高権限の認証情報に到達する経路（ワークフロー間のデータの流れ）を追跡できません。
●2026年6月18日にリリースされたGitHubの「actions/checkout v7」はこの問題を解決しますか？
部分的には解決します。このアップデートは、未レビューのフォークされたPRのヘッドコミットをチェックアウトして実行する最も一般的なパターンをブロックします。しかし、手動で信頼できないコードを実行するワークフローや、他の危険なイベント（issue_commentなど）、ワークフロー間のデータフロー攻撃には対応していません。そのため、完全な解決策ではなく、複数の対策の1つとして捉える必要があります。
●AIコーディングエージェントとの関連性はなぜ重要なのですか？
AIエージェントは、脆弱なパターンが多く含まれる既存のワークフローファイルを学習しているため、新しいCI/CD構成を生成する際に同じ脆弱性を高い確率で再現してしまいます。これにより、脆弱なリポジトリが機械的なスピードで指数関数的に増加し、攻撃対象領域が拡大し続けるという深刻な問題が生じています。
元記事: GitHub Actions Supply Chain Flaw Exposes Microsoft and Google to Free-Account Hijack