The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has placed Zammad, an open-source helpdesk platform, in its Known Exploited Vulnerabilities (KEV) catalog, according to Security Affairs. The report confirms at least one issue — CVE-2026-102489, a session hijack in Zammad that can be turned into remote code execution — and inclusion means CISA treats it as under active exploitation rather than hypothetical.
For Hong Kong teams running self-hosted open-source helpdesk stacks, that designation carries a different kind of weight from an ordinary CVE score. Under Binding Operational Directive 22-01, U.S. federal civilian executive branch agencies are required to remediate KEV-catalogued vulnerabilities within a set period — 21 days by default, unless the catalog entry specifies otherwise. Organisations outside the U.S. are not bound by the directive, but the underlying signal is the same: CISA adds a vulnerability to the KEV catalog only when it has evidence that the flaw is being exploited in the wild, not merely demonstrated in a proof of concept.
The distinction bites hardest in self-hosted deployments. Helpdesk platforms delivered as a service are patched by their vendor; a self-hosted Zammad instance leaves the entire remediation burden on the team that installed it, with no upstream auto-update to lean on. Zammad also tends to sit deep in an organisation's identity perimeter — frequently integrated with directory services such as Active Directory, and holding the live sessions of support staff who can reach internal systems. A session hijack from that position is not a contained application bug. It is a foothold.
Before acting on anything else, teams should read CVE-2026-102489 as the minimum known scope, not the full picture. KEV entries are updated as CISA catalogues additional flaws and adjusts due dates, so the CISA KEV catalog entry for Zammad should be consulted directly for the complete list of catalogued CVE identifiers and the specific remediation due-by date assigned to it. The same caution applies to patch availability: consult Zammad's published security advisories to confirm which versions are affected and which releases contain the fix, and do not assume a patched release has shipped for your deployment until the advisory says so. Where no patch exists, the practical mitigations below are offered as newsroom guidance, not as directives from CISA or Zammad — keep watching the advisory feed for the official line.
Remediation checklist for self-hosted Zammad operators
- Inventory your instances. Discovery is the step most often missed, and it is where most failures happen — forgotten shadow VMs, developer test clusters and staging environments rarely show up on patch registers. Run network scans for Zammad service signatures and cross-check asset inventories.
- Check your version against the advisories. Record the exact Zammad version running on each instance and compare it with the fixed versions listed in the vendor's security advisories.
- Apply the vendor patch when available. Schedule downtime and upgrade to the patched release rather than deferring to a routine maintenance window.
- Rotate sessions and credentials. If an affected instance was reachable from the public internet during the exploitation window, treat every active session and potentially exposed credential as compromised — invalidate sessions, rotate passwords and API tokens, and review authentication logs for anomalies.
- Review access paths. Confirm that the integration between Zammad and directory services is scoped to what the helpdesk genuinely needs; broad trust relationships multiply the blast radius of a session hijack.
- Monitor the KEV catalog and the vendor advisory feed for the full CVE list, the official due-by date and any additional fixes CISA or Zammad may publish.
The wider lesson for open-source infrastructure is that "we self-host" and "we are patched" are not the same statement. Adopting an open-source platform transfers responsibility, not risk. For teams in Hong Kong, Singapore or anywhere else without a local CERT advisory covering this issue, the CISA KEV entry and the vendor advisory are the primary sources — and neither is blocked by geography.
據 Security Affairs 報導，美國網絡安全及基礎設施安全局（CISA）已將開源客戶服務系統平台 Zammad 列入其「已知被利用漏洞」（Known Exploited Vulnerabilities，KEV）目錄。報道證實至少涉及一項漏洞 —— CVE-2026-102489，即 Zammad 的 session hijack（工作階段劫持）漏洞，可被進一步利用作 remote code execution（遠端代碼執行）。列入目錄意味著 CISA 認定該漏洞正在被實際利用，而非僅限於假設情境。
對於香港自行託管開源客戶服務系統架構的團隊而言，這一定性所代表的意義，與一般 CVE 評分截然不同。根據《具約束力的行動指令 22-01》（Binding Operational Directive 22-01），美國聯邦文職行政部門機構須在指定期限內修補已列入 KEV 目錄的漏洞 —— 預設期限為 21 天，除非目錄條目另有說明。非美國境內的機構並不受該指令約束，但背後的訊號是一樣的：CISA 只有在掌握證據顯示某項漏洞已在野外被實際利用時，才會將其加入 KEV 目錄，而非僅止於概念驗證（proof of concept）階段的展示。
這一點在自行託管的部署環境中影響最為深遠。以服務形式交付的客戶服務系統，由其供應商負責修補；而自行託管的 Zammad 實例，則令整個修補責任落在安裝它的團隊身上，沒有上游自動更新可以倚靠。此外，Zammad 往往身處機構身份管理範圍的深處 —— 常與 Active Directory 等 directory service 整合，並保存著能接觸內部系統的支援人員的即時工作階段。從這一位置發動的 session hijack，絕非一個受局限的應用程式缺陷，而是一個立足點（foothold）。
在採取任何其他行動之前，團隊應將 CVE-2026-102489 理解為已知範圍的下限，而非全貌。KEV 條目會隨著 CISA 收錄更多漏洞及調整修補限期而不斷更新，因此建議直接查閱 CISA KEV 目錄中有關 Zammad 的條目，以獲取已列入目錄的完整 CVE 編號清單及指派的具體修補限期。同樣的謹慎也適用於修補程序的可用性：請查閱 Zammad 發布的 security advisories（安全公告），以確認哪些版本受影響、哪些版本包含修補，切勿在公告確認之前，便假設已為你的部署環境推出修補版本。如目前尚無補丁，以下提供的實用緩解措施屬本刊編輯部的參考建議，並非來自 CISA 或 Zammad 的官方指令 —— 請持續監察公告更新，以掌握官方立場。
自行託管 Zammad 營運者修補清單
- 盤點你的實例。 Discovery（盤點）是最常被遺漏的一步，亦是大多數失誤的根源 —— 被遺忘的影子 VM（virtual machine）、開發測試叢集及預備環境，往往不會出現在修補登記表上。請執行網絡掃描，尋找 Zammad 服務特徵，並與資產清單交叉核對。
- 對照安全公告核實你的版本。 記錄每一個實例正在運行的確切 Zammad 版本，並與供應商 security advisories 所列出的已修復版本逐一比較。
- 在補丁可用時立即套用。 預留停機時間並升級至已修補的版本，而非拖延至例行維護時段。
- 輪換工作階段及憑證。 如受影響的實例在漏洞利用期間可從公眾互聯網存取，應視所有即時工作階段及可能外洩的憑證為已遭入侵 —— 使工作階段失效、輪換密碼及 API tokens，並檢查 authentication logs（認證日誌）有無異常。
- 審視存取路徑。 確認 Zammad 與 directory service 之間的整合，其權限範圍僅限於客戶服務系統實際所需的範疇；過寬的信任關係會大幅擴大 session hijack 的影響範圍。
- 監察 KEV 目錄及供應商公告更新，以掌握完整 CVE 清單、官方修補限期，以及 CISA 或 Zammad 日後可能發布的任何額外修補。
對開源基礎設施而言，更廣泛的教訓是：「我們自行託管」與「我們已完成修補」並非同一回事。採用一個開源平台，意味著責任的轉移，而非風險的轉移。對於香港、新加坡或其他地方沒有本地 CERT 就此事發出通告的團隊來說，CISA KEV 條目及供應商安全公告是最可靠的資料來源 —— 而兩者均不受地域限制。