Zammad零時差遭利用：AI agent令事件應變窗口進一步收窄

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-06

iThome報道指，荷蘭漏洞揭露協會（DIVD）在9月下旬發現遭入侵，調查後把初始入侵途徑連結至開源IT服務及客服系統Zammad的兩個零時差漏洞：CVE-2026-102489及CVE-2026-102490。美國網絡與基礎設施安全局（CISA）在10月2日把兩者加入已遭利用漏洞名單（KEV），意味已使用Zammad的機構不能只把事件視為研究層面的漏洞消息，應即時核實自身系統是否受影響及對外暴露情況。

事件另一個受關注之處，是DIVD初步認為活動由AI驅動，並公開了攻擊者指令碼中帶有大量自我解釋的截圖。不過，這仍是受害機構基於現有證據作出的初步判斷；DIVD表示未發現與已知駭客有關的線索，也未能完全排除針對性攻擊。因此，焦點應放在已確認的漏洞遭利用與資料外洩事實，而非過早為攻擊者身份或自動化程度下定論。

已遭利用，先找出誰在營運Zammad

據iThome報道，DIVD稱攻擊者把兩個漏洞結合後，可在數秒內挾持使用者連線、遙距執行程式碼，並把權限提升至root。DIVD確認有志工使用者資料外洩，涉及電郵地址及其他聯絡資料。對持有客戶查詢、支援紀錄、附件或帳戶資料的客服及工單平台來說，風險不僅限於server可用性，亦會延伸至個人資料、內部對話及後續釣魚攻擊。

香港的企業、NGO、學校及IT團隊若自行部署Zammad，第一步應是建立清晰的資產清單：系統部署於內部網絡、雲端還是託管環境；由誰持有系統管理權；實際運行版本、安裝方式及對外入口又是甚麼。不要只問業務部門有沒有「客服系統」；部分機構可能把工單平台交由外判商、集團IT或雲端供應商營運，前線部門未必知道底層產品正是Zammad。

盤點時應把正式環境、測試環境、備援實例和舊server一併納入。很多修補工作失敗，不是因為主系統沒有更新，而是被遺忘的測試站、過渡環境或仍可由互聯網存取的舊實例留在外面。若機構透過反向代理、單一登入或其他中介服務發佈平台，也應檢查實際流量是否仍能到達Zammad，以及日誌是否足以追溯可疑連線。

修補不應只停在版本更新

由於iThome提供的報道沒有列出安全版本、修補檔名稱或完整技術緩解步驟，管理員不應憑轉載文章猜測版本狀態。較穩妥的做法，是以Zammad官方安全公告及修補說明核對運行版本和受影響安裝路徑，按官方指示套用更新；同時參考CISA KEV的處置要求，將此工作納入有明確時限的修補流程。更新前後均應保存版本、變更時間、備份及驗證紀錄，讓日後覆核有據可查。

若系統由第三方營運，合約管理人不宜只收取「已完成修補」的一句回覆。應要求供應商確認受影響與否、現行版本、官方修補完成時間、對外曝露面，以及是否已審視事故期間的登入、管理操作和異常程序執行紀錄。供應商未必需要交出敏感日誌，但應提供可核實的處置摘要、責任人和後續監察安排；這也是第三方服務管理中最容易被忽略的一環。

更新本身亦不能抹去已發生的入侵。參照iThome對DIVD調查的描述，攻擊鏈涉及使用者連線、程式執行及高權限提升，機構在修補後應由具授權的資安人員檢視事故前後的身份驗證紀錄、管理帳戶變動、程序或排程異常、非預期的對外連線，以及資料匯出跡象。若發現可疑活動，應保全相關證據、隔離受影響系統並啟動既有事故應變程序，而不是自行刪除檔案令鑑識更困難。

AI agent改變的是攻防節奏

把今次個案概括為「AI已可自主入侵」會超出現有證據，但DIVD所描述的跡象，確實提示防守方要重新評估自動化帶來的速度問題。傳統攻擊行動常受人手分析、切換工具與交接限制；若部分偵測、決策與操作由agent串連，漏洞公開到大規模掃描、嘗試利用及整理結果之間的時間可能縮短。這是基於報道事實作出的風險分析，並非對今次攻擊者能力的確定結論。

對事件應變團隊而言，較短的攻擊窗口意味著通報與行動之間不能有太多手動斷層。資產擁有者、值班人員、雲端管理者和外判商需要預先定義誰可關閉對外存取、誰負責套用緊急修補、誰保存日誌，以及何時升級至管理層和法律或私隱團隊。這些安排平日看似繁瑣，到了零日漏洞已出現實際利用時，卻直接決定組織能否在數小時內完成基本控制。

同樣重要的是避免因「AI」標籤而忽略基本功。資產可見性、最小權限、管理帳戶保護、可用日誌、離線或受保護備份，以及第三方的修補承諾，仍是降低損失的核心。AI agent可能令攻擊方更快地重複和調整操作，但它不會自動消除防守方對曝露服務進行分段、監察與及時修補的必要性。反過來說，若機構連哪一台server在跑Zammad也未能確認，再先進的偵測工具也難以補救。

下一步看供應商通報與受影響範圍

DIVD表示在9月22日察覺惡意活動後，封鎖資料中心所有系統的存取並成立事件應變小組，且與Merlon Security進行鑑識；同日亦向Zammad開發團隊通報漏洞。其時間線說明，零時差處置往往同時涉及業務中斷、證據保存、漏洞通報和資料外洩評估，沒有單一「打補丁」動作可以完全代替。

接下來值得留意的是Zammad官方修補與安全公告的更新、KEV處置資訊，以及DIVD鑑識調查有否披露更明確的受影響範圍。使用Zammad的機構則應把今次事件轉化為可驗證的行動：確認資產與版本、依官方指引完成修補、追查入侵跡象，並向代管供應商取得具體證明。對管理客戶溝通資料的團隊而言，這比揣測攻擊背後是否完全由AI主導更迫切。