人間介入ゼロで「Jiraの認証情報」が流出 Copilotが見逃した1行の改修Copilotが「共著者」のコードに脆弱性 攻撃AIが5日で突破

Wizは、同社のセキュリティ研究特化型AIエージェントが、Snowflakeが公開しているGitHubリポジトリで脆弱性を発見し、Snowflake社内の「Jira」の認証情報アクセスに至った事例を公表した。脆弱性が顕在化してから5日後の出来事で、人間の介入はなかったという。

» 2026年09月15日 08時00分 公開
[@IT]

この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。

 Wizは2026年8月17日(米国時間)、同社のセキュリティ研究特化型AIエージェント「Wiz Red Agent」が、Snowflakeの「HackerOne」バグバウンティプログラムを通じて、同社の公開GitHubリポジトリで重大な脆弱(ぜいじゃく)性を発見したことを報告した。

 Wiz Red Agentは、GitHubのセキュリティ対策が見逃した「GitHub Actions」ワークフローの脆弱性を独自に発見して悪用し、Snowflake内部の「Jira」にある機密データへのアクセスを実証してみせたという。脆弱性が顕在化してから5日後の出来事であり、「人間の介入は一切なかった」と、Wizは説明している。

Copilotが「共著者」として見逃した「1行の改修」が、侵害の引き金に

 見つかったのは、Snowflakeに.NETアプリケーションから接続するためのクライアントライブラリのGitHubの公開リポジトリ「snowflakedb/snowflake-connector-net」におけるスクリプトインジェクションの脆弱性だ。前提として同リポジトリでは、ワークフローのトリガー条件に「イシューの新規作成(issues: opened)」が設定されていたことから、外部の不特定多数を含む任意のユーザーがイシューを1件投稿するだけで、自動的にワークフローが起動する仕組みとなっていた。

 2026年6月18日にリポジトリにマージされたプルリクエストで、リポジトリに元からあった安全なenvとjqの組み合わせが削除され、${{ github.event.issue.title }}を直接展開する形に置き換えていた。これがスクリプトインジェクションの入り口になった。

 「GitHub Advanced Security」のスキャンは、脆弱性を含むjira_issue.ymlを明示的に抽出していた。だが、この脆弱性は検出しなかった。同じプルリクエスト内で「Copilot Autofix」が貢献したのは、jira_close.ymlに対する別の修正だった。

 Wizは「Copilotがマージされたプルリクエストとコード変更を確認した共著者(co-author)となっており、重大な脆弱性に気付かないまま『問題なし』と判定した」と分析する。なお、その脆弱性を含んだコード自体がAIの支援によるものかどうかは不明だという。

Copilot Autofixが共著者として記録されたコミット(提供:Wiz) Copilot Autofixが共著者として記録されたコミット(提供:Wiz)

構文エラーを自力で直して認証情報を外部へ送信

 Wiz Red Agentは侵入を実証するため、ランナー内のJira認証情報を外部の検証用サーバ(コールバック先)へ送信する攻撃コード(ペイロード)を仕込んだIssueタイトルを作成・投稿した。

 最初の試行では、行の残りを無効化するために「#」を使用したところ、TITLE=$(...)の閉じかっこまでコメントに巻き込まれ、ランナーはシェルの構文エラーを出力した。Wiz Red Agentは構文エラーの内容を分析し、シェル構文を正しく閉じるよう攻撃文字列を修正して再実行した。これにより、認証情報の取得(コールバックの受信)に成功した。

 数秒のうちに、GitHub Actionsのランナーから、Base64でエンコードした認証情報を含むコールバックが届いた。送信されたトークンはqa@snowflake.netとして認証され、snowflakecomputing.atlassian.netのSnowflakeのエンジニアリング、セキュリティコンプライアンス、バグバウンティ管理の各プロジェクトに対する読み取りアクセスが可能となった。

外部へ送信されたトークンで到達したJiraの画面(提供:Wiz) 外部へ送信されたトークンで到達したJiraの画面(提供:Wiz)

 Snowflakeは報告を受けた当日中にワークフローを修正した。安全なenv変数とjq --argによる解析パターンを完全に復元し、問題となったJiraのトークンは失効させて更新している。開示のタイムラインは次の通り。

  • 2026年6月18日:プルリクエスト#1218のマージにより脆弱性が露出
  • 2026年6月23日:WizがHackerOne経由でSnowflakeへ報告
  • 2026年6月23日:SnowflakeのセキュリティチームにSlack通知
  • 2026年6月23日:Snowflakeがワークフローを修正
  • 2026年6月24日:Jiraのトークンを更新
  • 2026年7月25日:公開開示の期限

 詳細な監査ログの分析により、5日間の脆弱性露出期間中に外部の第三者がエンドポイントへアクセスした形跡はなく、異常なクエリは全てWizのテスト用アドレスと一致することが確認された。Wizは「PoC(概念実証)の検証中にアクセスした全てのデータを安全に削除した」としている。

AIエージェント時代への3つの警告

 Wizは、同事例から3つのポイントを挙げている。

 1点目は、AIによるコード生成には厳格な監督が必要なことだ。AIコーディングツールは確率的なパターンに基づいてコードを予測するため、非推奨または安全でないシェルの記述を意図せず導入することがある。

 AIが生成したプルリクエストにも、人間が書いたコードと同じ静的解析やセキュリティ精査が必要だ。

 2点目は、発見までの時間が縮まっていることだ。脆弱性が有効だったのはわずか5日間で、その間に自動化されたエージェントが発見と検証を済ませた。自動的な発見が数時間単位で起こる前提に立ち、迅速な修正サイクルと利用期間を最小限に絞った認証情報が要るとしている。

 3点目は、CI/CD(継続的インテグレーション/継続的デリバリー)のセキュリティ後退を防ぐ仕組みの構築だ。安全な実装パターンを明確に強制していないと、コード改修の際にセキュリティ対策が意図せず削られてしまうリスクがある。Snowflakeの事例でも、元々存在していた「env変数とjqによる安全な処理」が置き換わってしまい、既存のセキュリティ製品もその結果生じたインジェクションを検出できなかった。

Copyright © ITmedia, Inc. All Rights Reserved.

アイティメディアからのお知らせ

スポンサーからのお知らせPR

注目のテーマ

ID・パスワードから始める「引き算」のセキュリティ〜ゼロトラスト狂騒曲の果てに
その「AIコーディング」は本当に必要か?
Microsoft & Windows最前線2026
4AI by @IT - AIを作り、動かし、守り、生かす
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。