Snowflake脆弱性で何が起きたか
対象は公開リポジトリのsnowflakedb/snowflake-connector-netです。issueが立つと課題管理ツールのJira（ジラ）へ連携するワークフローに穴がありました。
発生から公開までの流れ（2026年）
"The injectable pattern was introduced just days earlier, on June 18, 2026, commit 4a1b8ce (PR #1218: \u201cSNOW-2069227: Update jira workflows\u201d) - co-authored by Copilot Autofix powered by AI."（The Code Change）／"June 23, 2026 - Wiz identified, exploited, and reported vulnerability to Snowflake via HackerOne (report #3819931)"／"June 24, 2026 - Jira token rotated"（いずれも Disclosure Timeline）— Wiz 公式ブログより
露出はわずか5日間だった
脆弱性が有効だった期間は5日しかありません。 それでも自律エージェントは見つけ、攻撃を成立させ、影響範囲の評価まで人手を介さずに終えています。自動での発見が数時間単位で起こる前提へ運用を合わせる必要があるとWizは指摘しています。
Snowflakeの対応は同日パッチ、翌日の認証情報入れ替えという速度でした。監査ログの精査でも露出期間中に外部の第三者がアクセスした形跡は無く、異常なクエリはすべてWizの試験用IPと一致しています。実証で触れたデータも削除済みです。
"Crucially, the vulnerability became live on June 18, 2026 - just five days before its discovery -when PR #1218 was merged."（Executive Summary）／"Comprehensive audit log analysis confirmed that no external third parties accessed the endpoint during the 5-day exposure window. All anomalous queries were strictly matched to Wiz's testing IPs."／"Same-Day Patching: Snowflake patched the workflow on June 23, 2026 (1dc7766, PR #1402), fully restoring the safe env: variable and jq --arg parsing pattern."（いずれも Remediation & Forensics）／"Wiz confirmed that all data accessed during proof-of-concept testing was securely deleted."（記事冒頭）— Wiz 公式ブログより
社内Jiraまで到達した認証情報
抜き取られたのはワークフローが持っていたJira（ジラ）の認証情報でした。トークンはqa@snowflake.netとして社内のAtlassian環境へ認証され、エンジニアリング・セキュリティコンプライアンス・バグバウンティ管理の各プロジェクトを読める状態にありました。
コードの変更を自動で検査・連携させるCI設定は、コード本体から見れば周辺の部品にすぎません。そこに置かれた1本のトークンが社内の課題管理まで通じていました。CIの設定ファイルは本番システムと同じ機密扱いで守るしかありません。
"The exfiltrated token authenticated as qa@snowflake.net to snowflakecomputing.atlassian.net, granting read access across Snowflake's engineering, security compliance, and bug bounty tracking projects."（Exploitation）— Wiz 公式ブログより
GitHub Actionsのスクリプトインジェクション
穴の作り方は教科書どおりでした。外部から自由に書ける文字列をそのままシェルスクリプトへ埋め込んでいます。コードの変更に応じて処理を自動実行するGitHub Actionsでは、この形が命令の差し込み（スクリプトインジェクション）を許します。
置き換えられた書き方
"The issue allowed an unauthenticated user to execute arbitrary commands within a GitHub Actions runner by opening a GitHub issue with a specially crafted title."（Executive Summary）／"The workflow triggered on issues: opened - meaning any GitHub user could fire it by opening an issue - and interpolated the attacker-controlled issue title directly into a shell script"（The Code Change）— Wiz 公式ブログより
安全な書き方を直接展開へ置き換えた
元のワークフローはissueタイトルを環境変数として渡し、jq --argでJSONを組み立てていました。文字列としてシェルに解釈させない定石どおりの実装です。PR #1218はこれを外し、テンプレート展開でタイトルをスクリプト本文へ直接埋め込む形に書き換えました。
sedで引用符を潰す処理は入っていました。ただし順番が逆です。GitHubのテンプレート展開はsedが動くより前に済んでおり、タイトルに含めたシングルクォートで文字列から抜け出せます。 ここから任意のコマンドが通りました。
"It removed the repository's existing safe pattern, which passed the issue title through an env: variable and built the JSON payload with jq. Instead it used the direct ${{ github.event.issue.title }} interpolation shown above. In other words, an AI "autofix" commit created the very injection vector."／"The sed escaping runs after GitHub's template expansion, a single quote in the title breaks out of echo '...' and allows arbitrary command execution."（いずれも The Code Change）— Wiz 公式ブログより
見せかけだけだった条件分岐
ワークフローには一見それらしいif:条件が付いていました。ボットからの実行を弾く意図の記述です。ところが評価対象はgithub.event.pull_request.user.loginでした。issueのイベントではgithub.event.pull_requestそのものが常にnullになります。
条件は「nullはボット名と等しくない」に縮み、誰が実行しても真になりました。ゲートに見えて誰も止めていません。書いた側の意図と実際の評価結果がずれたまま、レビューでも気づかれずに残った点が本件の急所です。
"However, on issues events, github.event.pull_request is always null. So the condition reduces to (null != 'whitesource-for-github-com[bot]'). This is always true, and every GitHub user passes the gate."（The Open "Security Gate"）— Wiz 公式ブログより
AIが見逃しAIが見つけた構図
注目を集めた理由は技術的な珍しさではありません。守る側と攻める側の両方にAIが立っていた点です。
それぞれのAIが果たした役割
レビュー側のAIは問題なしと判定した
Wizは公開の当日、記述を補足する更新を出しました。Copilotは共著者としてマージ済みのPRとコード変更を確認し、重大な脆弱性に気づかないまま問題なしと判定した。ただしコード変更そのものがAIの支援によるものかは不明である。この2点です。
つまり「AIが脆弱性を書いた」と断定はできません。確実なのはAIによるレビューが通してしまったという事実のほうです。 Copilotを狙う隠し指示がWord文書経由で広がった事例と同じく、問われているのは支援ツールを信頼の連鎖のどこに置くかです。
"August 17, 2026, 1957 UTC update: This blog has been updated to clarify that Copilot was a co-author that checked the merged PR and code change, and identified it as all-clear without noticing the critical vulnerabilities. It's unclear whether the code-change was AI-assisted."（記事冒頭の更新注記）— Wiz 公式ブログより
失敗した攻撃を自分で書き直した
攻撃側の挙動も特徴的でした。Red Agentは最初の試行でコメント記号を使い、シェルの構文エラーで失敗しています。ここで止まらず、返ってきたエラーを解析して構文の閉じ方を変え、二度目で認証情報の送出に成功しました。
人が横で見て直したわけではありません。試行錯誤の1周を自分で回せる点が従来の自動スキャナと自律エージェントを分ける差です。 標的選定から侵入まで自走する動きは自律型AI攻撃の実態でも観測されています。
"Rather than stopping or failing, Red Agent:"／"autonomously analyzed the syntax execution error"／"adjusted its payload to use ; echo ' to properly close the shell block, and"／"successfully received the out-of-band callback"（Exploitation・原文の箇条書きを ／ で連結）— Wiz 公式ブログより
英語のセキュリティ調査ブログは図とコードが混ざり、翻訳にかけると構造が崩れがちです。見出しと表を保ったままマークダウンに変換しておけば、社内共有もAIへの読み込みも一度で済みます。
開発現場が取るべき対策
Wizは技術的な結論として3点を挙げています。どれもAIを使う前提での運用設計に関わる話です。
Wizが挙げた3つの教訓
"AI coding tools predict code based on probabilistic patterns, which can inadvertently reintroduce deprecated or insecure shell patterns. AI-generated PRs must undergo the same static analysis and security scrutiny as human code."（Key Takeaways / AI Code Generation Demands Rigorous Oversight）— Wiz 公式ブログより
なぜその書き方だったかをAIは知らない
安全な書き方には理由があります。env変数とjqを使う形はシェルインジェクションを防ぐために選ばれたものでした。ところが自動化された支援ツールはその経緯を持ちません。
結果として確率的にありがちなパターンへ「直して」しまいます。AIが起こす退行は新しいバグではなく、対策済みだった古い穴の復活として現れます。 AIコーディング支援そのものを乗っ取るAgentjackingと併せて、支援ツールを信頼の外側に置く設計へ切り替える段階です。
"Automated AI assistants often lack historical context regarding why specific code patterns were chosen. In this incident, an automated PR removed a safe env: + jq parsing pattern that had been explicitly implemented to prevent shell injection."（Key Takeaways / Preventing AI Security Regressions）— Wiz 公式ブログより
認証情報は短命に、パッチは即日に
露出5日で突かれた事実は修正までの猶予がもう無いことを示します。Wizは自動発見が数時間単位で起こる前提へ運用を合わせるよう求め、短命な認証情報と速いパッチ適用を挙げました。
Snowflakeの対応はその要求水準を満たしています。報告当日のパッチ、翌日のトークン入れ替え、監査ログによる影響確認。穴を作らないことと同じ重さで、突かれてからの時間を削る設計が要ります。
"The vulnerability was live for only five days before an automated agent discovered and validated it. Security operations must adapt to a landscape where automated discovery occurs in hours, requiring rapid patch cycles and short-lived credentials."（Key Takeaways / Collapsing Discovery Windows）— Wiz 公式ブログより
Snowflake脆弱性で壊れたのは特別な仕組みではありません。誰でも書けるissueタイトルをそのままシェルに渡していただけです。防ぎ方は10年前から変わらず、変わったのは書く側とレビュー側と攻める側にAIが入った点だけでした。AIが関わる工程を増やすほど、人が置いたガードレールを機械が外していないかを見張る必要が出てきます。 それを後回しにすると、CI設定の1行が社内の課題管理まで通じます。
