ZammadのAIエージェントRCE：ネストされたテンプレートタグと1文字の修正

オープンソースのヘルプデスクであるZammadは、2026年8月4日に18件のセキュリティ修正を含むバージョン7.1.2をリリースしました。その一覧の最初に挙げられている修正は、AI Agent機能の設定フィールドにおけるリモートコード実行の脆弱性を解消します。この脆弱性はCVE-2026-84462で、同日にGitHubアドバイザリGHSA-gp3x-9xm8-rcj6で公開され、影響範囲は7.1.1以前のバージョン（7.1.1を含む）で稼働するすべてのセルフホスト型インストールです。AI Agentを作成または編集できる管理者は、エージェントのいずれかのフィールドに細工されたテキストを入力し、それを無効化するためのフィルターを回避して、Zammadをホストするサーバー上で任意のコマンドを実行できる可能性があります。アドバイザリの言葉を借りれば、「そのサーバーに保存されているすべてのデータを読み取り、改変、または破壊する」可能性を伴います。ほかのユーザーが操作する必要はありません。アドバイザリは「影響を受けるAI Agentが次にチケットを処理するときに、悪意のあるコードが自動的に実行される」と述べています。GitHubはCVSS 4.0で8.6、Highと評価しています。この記録、その重大度と危害タグ、およびその周辺で登録された項目はthe Orca AI Incident Archiveに保存されており、同アーカイブはこのインシデントをシリーズの残りの事例とともに掲載しています。

勧告が何を定めるか

2026年8月4日に公開されたGitHubアドバイザリは短く、しかもメカニズムと前提条件について異例なほど具体的です。「ZammadのAI Agent設定を保護するセキュリティフィルター」が「AI Agentのいずれかのフィールドに巧妙に細工されたテキストを入力することで回避できる」と説明し、行為者を正確に特定しています。「AI Agentを作成または編集する権限を持つ管理者がこれを悪用し、Zammadをホストするサーバー上で任意のコマンドを実行できる可能性がある」という内容です。影響を受ける範囲は7.1.1まで（7.1.1を含む）と記録され、修正済みバージョンは7.1.2です。報告者としてクレジットされているのはcolinthebomb1、公開アカウントはfliebe92です。このアドバイザリは概念実証もエクスプロイトの詳細も公開していません。

GitHubはこの脆弱性をHigh、CVSS 4.0で8.6と評価しており、ベクターはAV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:Hで、スコープ変更はありません。言い換えると、この脆弱性はネットワーク経由で低い複雑性のもと到達可能であり、攻撃要件もユーザー操作もなく、アプリケーション内ですでに高い権限を持つ攻撃者によって悪用され、Zammadインスタンス自体の機密性、完全性、可用性に高い影響を及ぼします。アドバイザリには3つの弱点が記載されています。CWE-20（不適切な入力検証）、CWE-94（コードインジェクション）、およびCWE-1336（テンプレートエンジンに関する分類で、MITREはこれを、エンジンによって処理される際にテンプレート式やその他のコード指令として解釈され得る特殊構文を中和できないことと定義しています）。

修正により1文字が変更されました

公開された修正はコミット e3b0c8df91ad2108c8305be23e8fe6f73fb9718d で、メッセージ「Maintenance: Improve ERB sanitizer.」とともに提出されました。GitHub には作者日付 2026年7月7日、コミット日付 2026年8月3日が記録されており、これはアドバイザリおよびリリースの1日前です。変更は2ファイルにわたり、lib/erb_sanitizer.rb の1行と、仕様の14追加行です。

一行が修正のすべてです。escape_tag メソッドは Ruby の sub を使用していました。これは文字列内のパターンの最初の一致を置換します。現在は gsub を使用しており、これはすべての一致を置換します。どちらのバージョンでも置換内容は同じです。`<%` と書かれた開始タグは `<%%` になり、これは ERB（Ruby のテンプレートエンジン）が評価せずにリテラルテキストとしてレンダリングする二重化形式です。アドバイザリは、どの AI Agent フィールドがそのテンプレートを保持しているかを明示していません。コミットは、そのテンプレートを不活性にするはずだったフィルターを特定しています。

sub を使うと、文字列内の最初の開始タグだけが無効化されていた。最初の開始タグの直後に2つ目の開始タグを置くペイロードはフィルタをすり抜ける。つまり <%<%= 1 + 1 %> は <%%<%= 1 + 1 %> となり、ERB は先頭の開始タグをテキストとして出力したうえで内側のタグを評価する。同じコミットで追加された回帰仕様は、この手口をあからさまに名指ししている——「単一タグの中にネストした開始タグを密輸する（escape-all-openers バイパス）」——そして、<%<%= 1 + 1 %> と二重にネストした <%<%<%= 1 + 1 %> の両方がリテラルテキストとしてレンダリングされなければならないと主張する。アドバイザリ自体は何も語っていないため、この仕様こそがフィルタがどう回避されたかについての最も明快な公的記録である。

このバグの形はZammad特有の珍しいものではなく一般的なものだ。最初の一致で止まるエスケーパーは、除去対象のシーケンスを2つ目として入れ子で含むあらゆる入力によって破られる。コミットメッセージはその変更をメンテナンスと呼んでいるが、これは1文字の堅牢化パッチが通常そういう形で進むからであり、だからこそ警告を担う必要があったのは差分ではなくアドバイザリだった。

アドバイザリからNVDまで7週間

NVDは2026年9月25日にCVE-2026-84462のレコードを公開した。これは勧告から7週間後で、最終更新は9月28日だった。このレコードは「Deferred」と記されており、これはNVDが独自の分析を公開していないことを意味する。また、そのメトリクスブロックでは8.6というスコアを二次指標としてsecurity-advisories@github.comに帰しており、これはCVE採番機関としてのGitHubによる採点であって、NVDによる独立した評価ではない。同じレコードにはCPE設定が一切含まれていないため、この脆弱性をバージョン付きの製品識別子に対応付けていない。

リリースノートではなくフィードでセルフホスト型ソフトウェアを追跡している人にとって、この2つの詳細はどちらも重要です。修正は8月4日に公開され、対処可能でした。機械可読な記録は9月25日に到着しましたが、その時点でも、CPEベースのスキャナーが照合に用いる製品識別子を欠いたままでした。7週間にわたり、この脆弱性に関する信頼できる説明はベンダーのアドバイザリとベンダーのリリースノートだけでした。

何が確立されており、何が確立されていないのか

確定済み: アドバイザリ、修正済みバージョン、CVSS スコア、コード変更はすべて Zammad および GitHub のアドバイザリデータベースに由来し、互いに一致している。NVD の記録は、番号付与機関の説明を独自の分析を加えることなく再現している。アーカイブはそれに基づいてこの項目の信頼度を A と評価しており、インシデントに異論はない。

未確認、または未記録: 勧告には概念実証（PoC）がなく、実際の悪用報告もない。FIRSTのEPSSは、2026年10月29日に公開されたスコアにおいて、CVE-2026-84462に今後30日間で悪用される確率を0.28パーセント、第20パーセンタイルとしている。アーカイブには実際の被害は記録されておらず、この項目は中程度の深刻度で登録されている——勧告自体のHigh区分を下回る。これらは異なる問いに答える別個の指標であり、脆弱性が何を許すかと、実際に何が起きたことが知られているかという違いであり、本稿はそれらを整合させようとはせず、両方を報告する。

独立した裏付けは乏しい。このCVEの報道を検索すると、脆弱性データベースが番号管理機関のテキストを再掲したものと、Zammad自身のリリースノートしか見つからない。この脆弱性を独自に報じたニュース媒体は見当たらない。これは記録に関する所見であって、記録への批判ではない。管理者アカウントを必要とするヘルプデスクのリモートコード実行は、報道を生むような種類の出来事ではなく、独立した記述が存在しないこと自体が、この記録が記録している内容の一部なのだ。

誰がそれをトリガーできたのか、そして何が変わったのか

Zammadの2026年8月4日付の7.1.2リリースノートには、そのバージョンで修正された18件の脆弱性が列挙されており、AI Agentテンプレートのバイパスが最初に挙げられています。ホスト型のお客様向けには「対応は不要です。お客様のインスタンスは当社チームにより既にパッチ適用と保護が完了しています」と記載されています。セルフホスト型のインストールについては、より断定的に「システムを保護するため、直ちに最新バージョンのZammadへのアップグレードを強く推奨します」と述べています。この勧告には回避策が示されておらず、記録にもアップグレード以外の緩和策は記載されていません。

特権要件は、攻撃ベクトルが示している以上に注意深く検討する価値がある。PR:H は、攻撃者がその脆弱性を利用する前に相当なアクセス権を必要とすることを意味し、ここでのそのアクセス権とは、Zammad のドキュメントが AI Agents を扱うにはそもそも必要だとしている admin.ai_agent 権限である。ヘルプデスクでは、それはしばしば、カテゴライザー、タガー、テキスト抽出ツールを調整するサービスチームのリーダーであり、必ずしもサーバーを管理する人ではない。アドバイザリ自身の表現「AI Agents を作成または編集する権限を持つ管理者」は、「誰でも」より狭く、「root」より広い。直ちにアップグレードできない場合、その権限を保持する人を狭めることで、そのコードパスに到達できる人の範囲が減る。これは攻撃ベクトルとドキュメントからの推論であり、ベンダーが公表した対策ではない。

主要ドキュメントはいずれも、言語モデルを悪用経路に置いていない。このコマンドは、エージェントの設定がレンダリングされるときに Zammad の Ruby プロセス内で実行される。アドバイザリ、コミット、リリースノートのいずれにも、モデルがペイロードを生成するとは書かれていない。AI Agent 機能が提供するのは、管理者が書き込み可能でテンプレート処理されるフィールドであり、AI は機構ではなく攻撃面である。記録が指し示すのはこのパターンだ。すなわち、エージェント定義——その指示、テンプレート、フィルター——は実行可能な設定であり、それを編集するのはセキュリティレビューではなくサポート業務を職務とする人々である。

Zammadの対処は妥当で地味だ。メソッド変更1件、回帰テスト2件、そして今回の穴と同時に他の17件の穴も塞ぐバージョンアップだ。引き継ぐ価値があるのはエクスポージャーモデルである。サポートリードにエージェントを定義させるヘルプデスクは、その同じサポートリードにサーバーが実行する何かを書かせることにもなる。その二つの間に立つのは、除去する構文の入れ子状のコピーをすべて正確に捉えなければならないフィルターだけだ。