Zammad 的 AI Agent RCE：一個巢狀範本標籤，一字母的修正

開源服務台軟體 Zammad 於 2026 年 8 月 4 日發布 7.1.2 版，內含十八項安全修正；清單中第一項修補的是其 AI Agent 功能設定欄位中的遠端程式碼執行漏洞。該漏洞為 CVE-2026-84462，同日於 GitHub 公告 GHSA-gp3x-9xm8-rcj6 中揭露，受影響範圍涵蓋所有自架安裝、版本最高至 7.1.1（含）。具備建立或編輯 AI Agent 權限的管理員，可在代理的某個欄位中輸入特製文字，繞過原本用來中和該內容的過濾機制，並在架設 Zammad 的伺服器上執行任意命令——正如公告所言，可能「讀取、修改或銷毀該伺服器上儲存的所有資料」。無需其他使用者介入：公告指出「惡意程式碼會在受影響的 AI Agent 下一次處理工單時自動執行」。GitHub 依 CVSS 4.0 評為高風險，分數 8.6。該紀錄、其嚴重性與危害標籤，以及周遭歸檔的條目，都收錄於Orca AI 事件檔案庫，該處將此事件與該系列其餘事件一併列出。

該公告所確立的事項

GitHub 安全性公告於 2026 年 8 月 4 日發布，內容簡短，且對機制與先決條件有異常具體的描述。公告指出，「保護 Zammad 的 AI Agent 設定」的「安全性篩選器」「可透過在 AI Agent 的其中一個欄位輸入特製文字來繞過」，並精確指明行為者：「具有建立或編輯 AI Agent 權限的管理員，可能利用此漏洞在託管 Zammad 的伺服器上執行任意命令。」受影響範圍記錄為最高包含 7.1.1，修補版本為 7.1.2。獲致謝的檢舉者為 colinthebomb1；發布帳號為 fliebe92。該公告未發布概念驗證，也未提供漏洞利用細節。

GitHub 將此漏洞評為高風險，在 CVSS 4.0 中得分為 8.6，向量為 AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H，且無範圍變更。詳細解讀後，這表示該漏洞可透過網路以低複雜度觸及，無需任何攻擊條件，也無需使用者互動，攻擊者只需已在應用程式內持有高權限，即會對 Zammad 執行個體本身的機密性、完整性與可用性造成高度影響。該公告列出三項弱點：CWE-20，輸入驗證不當；CWE-94，程式碼注入；以及 CWE-1336，此為範本引擎類別，MITRE 將其定義為未能中和特殊語法，「該語法在經引擎處理時，可被解譯為範本運算式或其他程式碼指示」。

這個修正改動了一個字母

公開修正為提交 e3b0c8df91ad2108c8305be23e8fe6f73fb9718d，提交訊息為「Maintenance: Improve ERB sanitizer」。GitHub 記錄的作者日期為 2026 年 7 月 7 日，提交日期為 2026 年 8 月 3 日，比公告與發佈早一天。此提交涉及兩個檔案：lib/erb_sanitizer.rb 的一行，以及規格中新增的十四行。

那一行就是整個修復。escape_tag 方法原本使用 Ruby 的 sub，它會替換字串中模式的第一個匹配；現在改用 gsub，會替換每一個匹配。兩個版本中的替換內容都相同：寫成 <% 的開頭會變成 <%%，這種加倍形式會讓 ERB（Ruby 的範本引擎）將其算繪為字面文字，而不是進行求值。公告並未指出是哪個 AI Agent 欄位帶有該範本；提交則指明了原本應該讓該範本失效的篩選器。

使用 sub 時，字串中只有第一個起始標記被中和。若攻擊負載緊接在第一個起始標記之後放置第二個起始標記，就能通過過濾器：<%<%= 1 + 1 %> 會變成 <%%<%= 1 + 1 %>，其中 ERB 會將開頭的起始標記當作文字輸出，然後對內層標籤求值。同一提交中加入的回歸測試規格直白地指出這個手法——「將巢狀起始標記夾帶進單一標籤內（escape-all-openers 繞過）」——並斷言 <%<%= 1 + 1 %> 與雙重巢狀的 <%<%<%= 1 + 1 %> 都必須呈現為字面文字。該規格是關於過濾器如何被繞過的最清楚公開說明，因為公告本身並未提供任何說明。

這個漏洞的形態是通用問題，而非 Zammad 特有的怪癖：一個在第一個匹配後就停止的轉義器，會被任何含有它所剝除序列之第二份嵌套副本的輸入攻破。提交訊息將這項變更稱為維護，而這正是單一字元加固修補程式通常的流通方式——也因此，警告必須由安全公告、而非差異檔來承載。

從發布資安公告到進入 NVD，只需七週

NVD 於 2026 年 9 月 25 日發布 CVE-2026-84462 的記錄，距離該安全公告發布已過了七週，並於 9 月 28 日最後修改。該記錄標示為「Deferred」，意即該機構尚未發布自身的分析；其指標區塊將 8.6 分歸因於 security-advisories@github.com，並列為次要指標——這是 GitHub 以 CVE 編號機構身分所做的評分，而非 NVD 的獨立評估。同一筆記錄完全沒有 CPE 組態，因此並未將該漏洞對應到具版本資訊的產品識別碼。

對於以訂閱源而非發布說明來追蹤自架軟體的人來說，這兩個細節都很重要。修正在 8 月 4 日就已公開且可直接採取行動；機器可讀的紀錄則要到 9 月 25 日才出現；而且即使到了那時，它仍未附上 CPE 型掃描器據以比對的產品識別碼。整整七週期間，關於這個漏洞的權威說明，就只有廠商的公告和廠商的發布說明。

什麼是已經確立的，什麼不是

已確認：安全公告、修補版本、CVSS 評分與程式碼變更皆來自 Zammad 及 GitHub 的安全公告資料庫，且彼此一致。NVD 的紀錄轉載了編號機構的描述，並未加入自身的分析。檔案庫據此將該條目的信心評為 A，且該事件並無爭議。

未確立，或未記錄：公告中沒有概念驗證，也沒有在實際環境中遭利用的報告。FIRST 的 EPSS 在 2026 年 10 月 29 日發布的分數中，給 CVE-2026-84462 的未來三十天遭利用機率為 0.28%，即第 20 百分位。該檔案未記錄任何實際損害，並將此條目歸為中度嚴重性——低於公告自身的高風險級別。這些是回答不同問題的獨立工具：一是該漏洞可能允許什麼，二是已知實際發生了什麼；本文兩者都報導，而不加以調和。

獨立佐證相當薄弱。搜尋這則 CVE 的相關報導，結果是轉載 CVE 編號授權機構文本的漏洞資料庫，以及 Zammad 自家的發布說明；似乎沒有任何新聞媒體獨立報導這項漏洞。這是關於記錄本身的一項發現，並非對它的批評：需要管理員帳號的服務台遠端程式碼執行，並不是會催生媒體報導的那類事件，而缺乏獨立記述本身，正是該記錄所記載的一部分。

誰可能觸發它，以及改變了什麼

Zammad 於 2026 年 8 月 4 日發布的 7.1.2 版發行說明，列出該版本修補的十八個漏洞，並將 AI Agent 範本繞過列為第一項。針對代管客戶，說明指出「無需採取任何行動。我們的團隊已為您的執行個體完成修補與防護。」針對自架安裝環境，措辭則更直接：「我們強烈建議立即升級至 Zammad 最新版本，以確保您的系統受到保護。」該公告未提供因應措施，紀錄中除升級外也未載明任何緩解措施。

權限要求值得比向量所呈現的更仔細檢視。PR:H 表示攻擊者必須先具備相當的存取權限，這個漏洞才有用；而在這裡，該權限就是 Zammad 文件所說，使用 AI Agents 時必備的 admin.ai_agent 權限。在服務台中，這通常是負責調整分類器、標籤器和文字擷取器的服務團隊主管，未必是管理伺服器的人。公告本身的措辭「具有建立或編輯 AI Agents 權限的管理員」，比「任何人」更窄，也比「root」更寬。若無法立即升級，縮小持有該權限的人員範圍，就能減少可觸及該程式碼路徑的人；這是從向量與文件推得的推論，並非廠商發布的補救措施。

所有主要文件都沒有把語言模型放進漏洞利用路徑中。當代理的設定被渲染時，該命令會在 Zammad 的 Ruby 程序內執行；安全公告、提交紀錄或版本說明中，都沒有描述模型產生酬載。AI Agent 功能提供可由管理員寫入、經範本處理的欄位，而 AI 是表面，而非機制。這就是紀錄所指出的模式：代理定義——其指示、範本與篩選器——是可執行設定，由本職為支援工作、而非安全審查的人所編輯。

Zammad 的補救措施既適度又乏味：一處方法變更、兩項回歸測試，以及一次版本號提升——它連同這次的漏洞一併補上了另外十七個漏洞。真正值得延續下去的是那套曝險模型。一個讓支援主管得以定義客服人員的客服系統，同樣也讓那位支援主管能寫入伺服器將執行的內容，而介於兩者之間唯一的屏障，就是一道必須對它所剝除之語法的每一份巢狀副本都判斷正確的過濾器。