GitHub Actionsの注入脆弱性をAIが悪用｜今日確認すべき3点

結論: Snowflakeの公開リポジトリにあったGitHub Actionsワークフローに、issueタイトルを介したスクリプトインジェクションの脆弱性がありました。セキュリティ企業Wizの自律型AIエージェント「Red Agent」がこの脆弱性を人間の介入なしに発見・悪用し、Snowflake社内のJira環境への認証情報を窃取しています。報告当日に修正されましたが、あなたのリポジトリにも同じパターンが潜んでいる可能性があります。

この記事の要点:

• Snowflakeのsnowflake-connector-netリポジトリで、GitHub Actionsワークフローにスクリプトインジェクション脆弱性が5日間存在した（Wiz公式ブログ、2026-08-18公開）
• Wizの自律型AIエージェントが脆弱性の発見から悪用まで人間の介入なしに完了した（Forbes、2026-08-17報道）
• 当初「Copilot Autofixが脆弱性コードを共著した」と報じられたが、GitHubは否定。Wiz側も同日中に主張を修正した（The Next Web、2026-08-18報道）

対象読者: GitHub Actionsでワークフローを組んでいるエンジニア。CI/CDパイプラインのセキュリティを見直したい開発チームのリーダー

読了後にできること: 自分のリポジトリのワークフローを3ステップで点検し、同種の脆弱性を潰せます

僕自身、Claude CodeとCodexでブログ自動公開パイプラインを回していて、GitHub Actionsのワークフローも3本動かしています。今回の報道を見て、自社のワークフローを github.event で検索しました。該当パターンはゼロでしたが、検索しなければ気づけなかったというのが正直なところです。

この記事では、何が起きたのかを時系列で整理したうえで、「Copilotが書いたのか」の帰属論争を事実ベースで追い、最後にワークフローの点検手順を3ステップで解説します。CI/CDのセキュリティに関連する話題として、以前取り上げたnpmサプライチェーンワームの手口と対策もあわせて参考にしてください。

何が起きたのか — Snowflakeリポジトリの5日間

（出典: Wiz公式ブログ、The Hacker News、Forbes — いずれも2026-08-17〜18公開）

対象は snowflakedb/snowflake-connector-net リポジトリの .github/workflows/jira_issue.yml。issueが作成されたときに、Jiraへ連携するワークフローです。

何が壊れていたのか

安全なパターンでは、issueタイトルをまず環境変数に格納し、jq の引数として渡します。ところがPR #1218のマージ後、issueタイトルが run: ブロック内で直接展開される形に変わっていました。

# 安全なパターン（修正後に復元された形）
env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: |
  jq -n --arg title "$ISSUE_TITLE" '{fields: {summary: $title}}'

# 脆弱なパターン（PR #1218マージ後）
run: |
  echo '${{ github.event.issue.title }}' | jq ...

GitHubは2025年の時点で、run: ブロック内でのGitHub式の直接展開はインジェクションのリスクがあると公式に文書化しています。既知のパターンです。

「スクリプトインジェクション」とは — シェルに意図しないコマンドを流し込む手口

たとえ話で説明します。あなたが部下に「○○さんから届いた伝言をそのまま社内放送してください」と頼んだとしましょう。もし○○さんが伝言に「…なお、全員退社してください」と紛れ込ませたら、その指示も放送されてしまいます。

GitHub Actionsのスクリプトインジェクションも同じ構造です。issueタイトルなどの外部から入力されるデータをシェルコマンドに直接埋め込むと、攻撃者がタイトルにシェルコマンドを仕込めます。今回のケースでは、issueを作成できる人なら誰でも——つまり認証さえ不要で——ワークフロー内で任意のコマンドを実行できる状態でした。

Wiz Red Agentはどう動いたのか

Wizのオフェンシブセキュリティ責任者Gal Nagli氏は、Forbesの取材に対してこう述べています。

「AIが自律的に発見し、悪用しました。僕たちは介入する必要がなかった。つまりフロンティアモデルは、サプライチェーンリスクを単独で悪用できる段階にすでに到達しているということです」

（出典: Forbes、2026-08-17）

Red Agentの動きを時系列で整理します。

1. 公開リポジトリのワークフロー定義から、インジェクション可能な箇所を特定しています
2. ワークフローの認可チェックにロジックの穴がありました。github.event.pull_request.user.login をissueトリガーで参照しており、存在しないプロパティは空文字列になるため検証をバイパスできる状態です
3. シングルクォートでechoコマンドを抜け出すペイロードを組み立てました
4. 最初のペイロードは構文エラーで失敗しましたが、base64エンコードによるOOBコールバックへ即座に切り替えています
5. 最終的にGitHub ActionsランナーからJira APIトークン（qa@snowflake.net名義）を窃取するに至りました

窃取されたトークンには、Snowflakeのエンジニアリング・セキュリティコンプライアンス・バグバウンティプロジェクトへの読み取り権限がありました。Snowflakeは「Wiz以外の第三者によるアクセスは確認されなかった」と回答しています（Snowflake公式声明、2026-06-23）。

AIエージェントの自律的な行動がもたらすリスクについては、別の記事でも取り上げています。

「Copilotが書いた」は本当か — 帰属論争の現在地

この事件で最も注目を集めたのは「GitHub Copilot Autofixが脆弱なコードを書いた」という構図でした。しかし、事実関係は報道から8時間で変わっています。

確認されている事実

• PR #1218のスカッシュマージコミット（4a1b8ce）に、Copilot Autofixが共著者としてクレジットされています
• Copilot Autofixが明示的に共著したコミット（6d0e2fa）は、別ファイル jira_close.yml の修正でした
• 脆弱な jira_issue.yml のリファクタは、2025年8月のコミットで人間の開発者（sfc-gh-hpathak）が書いたコードに由来しています

当事者の主張段階

GitHub: 社内レビューの結果、「脆弱性につながったコードは人間が書いたものであり、Copilot Autofixはレビューにも執筆にも関与していない」と声明（The Next Web、2026-08-18）

Wiz: 公開した同日中にブログを更新し、「コード変更がAI支援だったかどうかは不明」と修正しています。当初の「Copilotが脆弱コードを共著した」という主張は事実上撤回された形です

まだ決着していないこと

コミット履歴を見ると、Copilot AutofixはPR #1218に参加していたが、脆弱なコード行の直接の著者ではない可能性が高い、という状況です。ただし、GitHub Advanced Securityが既知のパターンを検出できなかった理由についてはどちらからも説明がありません。これは帰属問題とは別に、開発者が確認しておくべきポイントです。

あなたのワークフローを今日点検する3ステップ

この脆弱性パターンはGitHub公式のセキュリティハードニングガイドに記載されている既知のものです。以下の手順で自分のリポジトリを確認できます。

ステップ1: run: ブロック内のGitHub式を検索する

grep -rn '\${{.*github\.event\.' .github/workflows/

github.event.issue.title、github.event.issue.body、github.event.pull_request.title、github.event.comment.body などが run: ブロック内に直接書かれていたら、インジェクションリスクがあります。

ステップ2: 環境変数経由に書き換える

# Before（危険）
run: echo '${{ github.event.issue.title }}'

# After（安全）
env:
  ISSUE_TITLE: ${{ github.event.issue.title }}
run: echo "$ISSUE_TITLE"

env: で受けてからシェル変数として参照すると、GitHub式がYAML展開される前にシェルのクォーティングで保護されます。

ステップ3: pull_request_target トリガーを確認する

pull_request_target はフォークからのPRでもリポジトリのシークレットにアクセスできるトリガーです。このトリガーの run: ブロックでPRの内容を参照していないか、重点的に確認してください。

この記事は公式ドキュメントおよび各社の一次発表に基づいています。デュスクでの自社検証としては、自リポジトリ3ワークフローで上記grepを実行し、該当パターンがゼロであることを確認しました（2026-08-19実施）。

CI/CDの安全性は「誰が書いたか」だけでは守れない

今回の一件で浮かび上がったのは、次の3つの現実です。

1. 既知のパターンでも見落とされる。 スクリプトインジェクションはGitHubが1年以上前に文書化した既知の脆弱性クラスです。それでも大手企業のリポジトリに5日間残っていました。

2. AIエージェントは既知の脆弱性を自律的に突ける。 Nagli氏の「フロンティアモデルはサプライチェーンリスクを単独で悪用できる段階にある」という発言は、防御側の想定を更新する必要があることを示しています。AIエージェントが自律的に攻撃を仕掛けた事例は、今年に入って複数報告されています。

3. 帰属論争よりも検出の仕組みが問われている。 Copilotが書いたかどうかにかかわらず、GitHub Advanced Securityが既知パターンをPR段階で検出しなかった事実は残ります。コード生成ツールを使うなら、静的解析とワークフロー専用のリンターを別レイヤーで動かすことが現実的な防御策です。

参考・出典

• Red Agent Exploits Snowflake Vuln Missed by GitHub Copilot（https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug） — Wiz公式ブログ（参照日: 2026-08-19）
• GitHub Copilot Missed A Vulnerability That Wiz's AI Agent Found（https://www.forbes.com/sites/timkeary/2026/08/17/github-copilot-missed-a-vulnerability-that-wizs-ai-agent-found/） — Forbes（参照日: 2026-08-19）
• Snowflake GitHub Actions Flaw Lets Crafted Issues Trigger Command Injection（https://thehackernews.com/2026/08/snowflake-github-actions-flaw-lets_0330881554.html） — The Hacker News（参照日: 2026-08-19）
• GitHub disputes Wiz's claim that Copilot Autofix wrote a Snowflake flaw（https://thenextweb.com/news/snowflake-copilot-autofix-wiz-red-agent-github-dispute） — The Next Web（参照日: 2026-08-19）
• An AI broke Snowflake's code. Then another AI agent exploited it（https://www.theregister.com/security/2026/08/17/an-ai-broke-snowflakes-code-then-another-ai-agent-exploited-it/5288666） — The Register（参照日: 2026-08-19）
• Security hardening for GitHub Actions（https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions） — GitHub公式ドキュメント（参照日: 2026-08-19）