powered by TechFeed
表示モード
Deep Dive

AIエージェントがSnowflakeのGitHub Actionsを自律的に侵害、内部Jiraトークン取得まで5日・2回の試行で完結 — GitHub Advanced Securityも検出できなかった脆弱性

8月20日、Cyber Security Newsが「AI Agent Hacks Snowflake GitHub Workflow and Reaches Internal Jira」と題した記事を公開した。Wiz ResearchのAIエージェントが、Snowflakeのパブリックリポジトリに存在したGitHub Actionsの脆弱性を人間の誘導なしに自律的に発見・悪用し、Snowflakeの内部Jiraインスタンスへの読み取りアクセスを取得した——この事例の詳細を紹介する。

8月20日、Cyber Security Newsが「AI Agent Hacks Snowflake GitHub Workflow and Reaches Internal Jira」と題した記事を公開した。Wiz ResearchのAIエージェントが、Snowflakeのパブリックリポジトリに存在したGitHub Actionsの脆弱性を人間の誘導なしに自律的に発見・悪用し、Snowflakeの内部Jiraインスタンスへの読み取りアクセスを取得した——この事例の詳細を紹介する。


AIエージェントが企業インフラへ自律侵入

Wiz Researchが開発した自律型AIセキュリティエージェント「Wiz Red Agent」は、SnowflakeのGitHubパブリックリポジトリ「snowflake-connector-net」を標的に、脆弱性の発見からエクスプロイトまでを完全自律で完結させた。人間が攻撃を誘導することは一切なかった。

結果として取得されたのは、Snowflakeの内部Jiraサービスアカウントのトークンだ。エンジニアリング、セキュリティコンプライアンス、バグバウンティ追跡プロジェクトの内容が参照可能な状態になった。このエクスプロイトが示す最大の含意は技術的な脆弱性の存在ではなく、「脆弱性の公開からAIによる悪用完了までの時間が5日・2回の試行に収まった」という速度の変化にある。


シェルスクリプト1行のミスがJiraトークン流出まで直結

脆弱性の起点はjira_issue.ymlというワークフローファイルだ。このファイルは、GitHubにIssueが作成されると自動でJiraチケットを起票する仕組みを担っていた。

問題は2026年6月18日にマージされたPR #1218にある。それ以前は環境変数とjqによるパースで安全に処理していたIssueタイトルを、このPRがシェルスクリプト内に直接展開(文字列補間)する方式に書き換えてしまった。

GitHubのテンプレート展開はシェルのエスケープ処理より先に走るため、Issueタイトルにシングルクォート1つを含めるだけでスクリプトを抜け出し、任意コマンドを注入できる状態になっていた。さらに、アクセスを制限するはずの条件分岐がissue_openedイベント時に常にtrueと評価されるバグも重なり、任意のGitHubユーザーがこの脆弱性をトリガーできた。


GitHub Advanced SecurityもCopilotも見逃した

見過ごせない点として、GitHub Advanced Securityがこの脆弱性を含むコードをスキャンしたにもかかわらず検出に失敗している。

同じPRには、関連する別ワークフローファイルjira_close.ymlへのCopilotが関与した変更も含まれていた。Wizの説明によれば、Copilotの関与はあくまでその関連ファイルに限定されており、脆弱なインジェクションを含むjira_issue.yml自体をCopilotが作成したとは断言できない。ただし、マージ前のレビュー段階で、AIツールを含む誰も(何も)致命的な欠陥を捕捉できなかった事実は重い。

AIが支援するコーディングは、脆弱なパターンを排除するのと同じくらい容易に再導入しうる——記事はこの点を明示的に問題提起している。


脆弱性公開から5日、2回目の試行で突破

Red Agentが脆弱なコードを発見したのは、PRがマージされてからわずか5日後の6月23日だ。

エージェントはbase64エンコードしたアウトオブバンドコールバックを仕込んだ悪意あるIssueタイトルを生成した。最初のペイロードはコメント文字の使い方がまずくシェル構文が壊れたが、エージェントは自律的にbashのエラーを診断してペイロードを書き直し、2回目の試行で成功させた。

数秒後、WizのリスナーはAzureホストのランナーからbase64エンコードされたJira APIトークンのコールバックを受信した。そのトークンはサービスアカウント**qa@snowflake.net**に紐づいており、SnowflakeのAtlassianインスタンスへの認証に成功。エンジニアリング、セキュリティコンプライアンス、バグバウンティ追跡プロジェクトの内容が参照可能な状態になった。


Snowflakeの対応と教訓

SnowflakeはHackerOne経由で報告を受けた当日中にワークフローを修正し、露出したJiraトークンをローテーションした。監査ログの確認によって、露出期間中にアクセスがあったのはWizのテストトラフィックのみだったことも確認されている。なお、PoC中にアクセスされたデータが削除済みである点については、元記事の記述に基づくものであり、Snowflakeによる公式発表内容の確認を推奨する。

この事例が示すのは、CI/CDパイプラインにおける3つの構造的な問題だ。

  • ユーザー入力のシェル直接展開:環境変数やjqによる安全なパターンからの逸脱が直接的な原因となった
  • 長命なサービスアカウントトークン:短命なクレデンシャルであれば、流出しても影響範囲は限定される
  • 静的解析ツールの限界:GitHub Advanced Securityが見逃した事実は、既存ツールへの過信が危険であることを示している

そして記事が最も強調するのは、「発見から悪用までの時間軸」の変化だ。従来であれば数週間かかっていた脆弱性の発見〜エクスプロイトのサイクルが、自律型AIエージェントによって数時間に圧縮される時代に入りつつある。防御側も同じ速度で自動化を進めなければ、この非対称性は拡大する一方だ。


詳細はAI Agent Hacks Snowflake GitHub Workflow and Reaches Internal Jiraを参照していただきたい。