エージェント型ワークフローインジェクション（CVE-2026-44246）に関する再現可能な脆弱および修正済みのGitHub Actionsフィクスチャ。測定された検出器カバレッジと緩和ガイダンス付き。

これはテンプレートインジェクションではない。シェルとして評価されるものは何もない。ペイロードは散文であり、インタプリタはモデルである。だからこそ、いつものアドバイス——変数をクォートせよ、eval するな——は当てはまらず、以下の修正が入力のエスケープではなく、エージェントが何に到達できるかに関するものになっている。

知っておく価値のある部分: 修正コミットは修正ではない

nnU-Net はこのワークフローを2つのコミットで強化しており、「前」と「後」を二値として扱う検出器は真ん中のものを誤る。

誰もが修正と呼ぶであろうコミット——そのメッセージは*「hardened issue and PR agents」*——は gh issue edit を削除し、ラベルを .github/scripts/safe-label.sh 経由にしたが、Bash(gh issue comment:*) をエージェントに残した。エージェントは依然としてコメントするよう誘導される可能性があり、許可リストパターン gh issue comment:* はトリガーとなった issue にスコープされていないため、ターゲットはモデルが選ぶままだった。これを閉じたのは3番目のコミットだけである: エージェントは /tmp/issue-comment.md を書き、後続の非エージェントステップがイベントから取得した ISSUE: ${{ github.event.issue.number }} を使ってそれを投稿する。

そこから2つのことが導かれ、それがこのリポジトリが単なる2つのファイルではない理由である:

「修正済み」はバージョンではなくリビジョンに関する主張である。 v2.4.1 が修正リリースとして引用されているが、その .github/workflows/ には codespell.yml しか含まれていない——エージェントワークフローはそのタグには全く存在しない。タグから修正を検証することはできない; コミットをピン留めする必要がある。

permissions ブロックは決して変わらない。 issues: write は3つのリビジョンすべてに存在し正しく、最後のものも含めて、後続のステップがそれを必要とするためである。permissions だけに注目する検出器は、リビジョン1とリビジョン3を区別できない。それらを区別するのは、エージェントが何を呼び出せるかである。

実測カバレッジ

3つの検出器を、両方のフィクスチャと3つの実際のリビジョンすべてに対して実行した。完全な生出力とツールのバージョンは results.md にある。

ここで単純に「間違っている」検出器はない——それらは異なる問いに答えている:

• zizmor は汎用の Actions 監査ツールである。ピン留めされたアクションと認証情報の永続化の衛生状態について、3つのリビジョンすべてで同一に報告する。設計上この分類の範囲外であり、含めているのは「よく知られたリンターが脆弱なファイルでクリーンだった」ことが健康証明と誤解されやすいからである。
• sisakulint は専用の AI ルールを持ち、ここで CVE 自身のメカニズムを名指しする唯一のツールである: ai-action-prompt-injection は、issue 本文が prompt: に補間されている脆弱なリビジョンで発火し、補間がなくなると止まる。正しい。後続リビジョンに関するその検出結果は、それに基づいて行動する前に読む価値がある——ai-action-excessive-tools は Write を指摘するが、このワークフローは後続のステップが投稿するファイルを書くために意図的にそれを使っている; そして ai-action-execution-order はエージェントを最後に置くことを求めるが、これはまさにこの設計が避けていることであり、特権ステップはモデルのターンが終わった後に来る。
• agentbound は、ジョブの permissions ではなくエージェントのツール許可リストを読むことで、リビジョン2とリビジョン3を区別する唯一のツールである。その ci-agent-missing-author-association 検出結果は後続リビジョンで critical として報告され、自身の README はそれを偽陽性ではなく過剰に厳しいものと説明している: auto-triage は誰からでも到達可能であることが意図されている。

ここにあるすべてのツールには、その正確な条件について作成者がすでに熟考していたリビジョンに対して報告する検出結果がある。それはヒューリスティックの正常な状態であり、カバレッジ表が合否列よりも有用である理由である。

使い方

benchmark.sh は、インストールされていない検出器を黙ってスキップするのではなく、欠落として報告する。なぜなら、ツールを静かに省略したカバレッジ表は、そのツールについて何も証明しないからである。

フィクスチャは縮小された形であり、このリポジトリのために書かれ、他の部分と同様に MIT ライセンスである。それらはコピーではなくメカニズムに忠実である: fixtures/vulnerable.yml は4つの条件だけを持ち、fixtures/fixed.yml は同じファイルで、重要な6つの変更がそれぞれ注釈付きで施されている。ルールを追加するなら、これら2つのファイルが正しく処理すべき最小の入力である。

2つのインターフェースの癖があり、スクリプトで処理されているが知っておく価値がある:

• sisakulint は git リポジトリ外のファイルを解析しない。 1つ渡すと、not found と表示して 3 で終了する。監視されなければ、それはクリーンなスキャンと同一に見える。
• agentbound の JSON path はベースネームであるため、同じ名前のファイルに対するディレクトリスキャンは曖昧になる。

修正する

検出は簡単な半分である。docs/mitigations.md はもう半分を扱う: エージェントの権限をどのように境界付けるか、層を1つの問い——この制御はモデルが従うことを選ぶことに依存しているか?——によって順位付けして。

その順位付けが要点のすべてである。プロンプト内の指示は入力であり、ガード節ではない; ターゲットを名指しするツールパターン、あるいはエージェントが決して持たないトークンは境界である。このガイドは「モデルが間違ったことをできない」から「モデルは間違ったことをしないよう求められた」へと下っていき、チェックリストと nnU-Net の進化を作例として示す。

fixtures/fixed.yml はその6つの変更それぞれに、それが実装する層およびそれが load-bearing かどうかのタグを付ける——そのうち2つはそうではなく、読者がファイルを過大評価しないようにそのようにラベル付けされている。

出所

実行時にコミット SHA によって取得され、決してベンダリングされない:

nnU-Net の設定のコピーはここで再配布されていない; 取得を再実行し、上記のブロブとバイト単位で自分で比較せよ。

スコープ

これは検出エンジニアリングの成果物である。エクスプロイトは含まれず、ここにあるものはライブのワークフローに対してテストされていない——脆弱なリビジョンは静的ファイルであり、nnU-Net の履歴ですでに公開されており、公開されたアドバイザリで参照されている。フィクスチャは do not deploy とマークされている。なぜならそれらはコピーされるためではなく、検出されるために存在するからである。

この分類の検出器を保守していて表に行を追加したいなら、ベンチマークスクリプトがインターフェースである: targets に対してツールを実行しその検出結果を出力するセクションを追加すれば、フィクスチャとピン留めされたリビジョンが残りをやってくれる。

MIT。