AIエージェント、GitHub Actionsの脆弱性を発見しSnowflake社内Jiraへ到達

脆弱性を自律的に探索するAIエージェントが、Snowflakeの公開リポジトリ内にある欠陥を独自に発見し、それを足がかりに同社の社内Jiraシステムへのアクセスに成功しました。この脆弱性は発見された時点でわずか5日前に生まれたばかりのものでしたが、注目すべきことに、その間GitHub Copilotがコードをレビューしていたにもかかわらず、危険な箇所を検知できていませんでした。

WizのRed Agentが脆弱性を発見

Wizの研究者らがこの問題を特定したのは、Snowflakeの公開GitHubリポジトリを調査していた自律型スキャンツール「Red Agent」によるものです。この脆弱性は、snowflakedb/snowflake-connector-netプロジェクト内のGitHub Actionsワークフロースクリプトに存在していました。GitHubユーザーであれば誰でも、特別に細工したタイトルで新規Issueを作成するだけで、この脆弱なプロセスを発生させることができました。

1件のプルリクエストがシェルインジェクションを招いた経緯

問題のあるコードが導入されたのは2026年6月18日、プルリクエスト#1218のマージによるものでした。それ以前は、Issueのタイトルはまず環境変数に格納され、その後jqユーティリティに安全に渡してデータを構築する仕組みになっていました。しかし新しいバージョンでは、Issueタイトルの内容がシェルコマンドへ直接挿入されるようになっていました。エスケープされていない引用符が1つあれば、想定されていた文字列から抜け出し、サーバーに攻撃者が指定した任意のコマンドを実行させることが可能な状態でした。

GitHub Copilotはレビューしたが見逃していた

Wizは、今回の事態におけるGitHub Copilotの役割に特に注目しています。該当のコミット記録には共著者として「Copilot Autofix powered by AI」の名が記載されており、Copilotがこの変更をレビューした際には安全と判定し、重大な欠陥を検知できていませんでした。ただしWizは、脆弱なコード片そのものが本当にAIによって書かれたものかどうかについては断定できないとも慎重に説明しています。

ワークフローが無制限に実行されないようにするための追加の安全対策も、意図した通りには機能していませんでした。一般ユーザーが通常のIssueを作成すると、検証対象のフィールドの1つが常に空になってしまい、その結果、防御条件はどのGitHubユーザーに対しても例外なく「真」と評価される仕組みになっていました。つまり、この防壁は実質的に誰も食い止めていなかったのです。

Red Agentが発見を認証情報窃取にまでエスカレート

Red Agentは脆弱性の特定だけにとどまりませんでした。同エージェントは自律的に検証用リクエストを組み立て、GitHub Actionsの実行環境からJiraの認証情報を抽出しようと試みました。最初の試行では構文エラーが返されましたが、システムはそのレスポンスを分析してコマンドを調整し、再試行しました。数秒のうちに、Wizは[email protected]アカウントの下でSnowflakeの社内Jiraインスタンスへのアクセスを許可する認証情報を取得しました。

流出した鍵が機密性の高い社内プロジェクトへのアクセスを許していた

侵害された鍵は、社内の製品開発手法、セキュリティコンプライアンス手順、そして同社の脆弱性報奨金プログラムに関連するSnowflakeのプロジェクトに対する読み取りアクセス権を与えるものでした。つまり、公開リポジトリに存在したたった1つの脆弱性が、同社の社内情報への直接的な侵入経路を開いてしまったことになります。

Snowflakeの対応と修復

Wizは6月23日にこの問題をSnowflakeへ報告しました。同社は同日中に脆弱なスクリプトを修正し、入力データを扱う本来の安全な方式に戻すとともに、6月24日には流出したJiraの鍵をローテーションしました。調査担当者がアクセスログを確認したところ、脆弱性が5日間有効だった期間中に、第三者がこれを悪用した形跡は見つかりませんでした。Snowflakeは、不正アクセスの兆候は確認されなかったと述べています。

Wizは、AIシステムが生成または承認した変更についても、人間が書いたコードと同等の厳格さと精査をもってレビューするよう推奨しています。