If you self-host Zammad — or any open-source helpdesk in the same category — this is the week to confirm exactly what version you're running and who can reach it.
The Dutch Institute for Vulnerability Disclosure (DIVD) says the breach of its own network was made possible by a chain of two zero-day vulnerabilities in Zammad, the open-source ticketing system, according to a report by BleepingComputer. DIVD, which exists to coordinate vulnerability disclosure for other organisations, named itself as the victim.
The choice to disclose the incident publicly is itself notable. It means a security organisation running its own infrastructure has documented its compromise rather than quietly containing it — offering the wider ecosystem a partial playbook, even where the technical details remain incomplete.
The AI claim is DIVD's and remains uncorroborated
DIVD has characterised the intrusion as AI-driven. That framing, as relayed in the BleepingComputer report, is one organisation's assessment of its own incident; it has not been independently corroborated, and the reviewed material does not specify what exactly the label refers to — AI-assisted reconnaissance and target selection, or attacker tooling used throughout the intrusion. Readers should treat the description as a single-actor attribution rather than an established technical finding.
What is not yet known
The reported material does not identify CVE identifiers, affected Zammad versions, or the patch status. As of publication of this article on 30 September 2026, those gaps remain open in the source coverage — and downstream summaries that fill them in should be treated with suspicion. For administrators, the practical consequence is simple: you cannot currently assume you are patched, and you should not assume you are exposed either until you have checked Zammad's own advisory and release channels.
Why a helpdesk is a high-value target
A ticketing system is not just a queue for user complaints. It indexes internal access. It hosts password-reset flows that hand an attacker account-takeover material without brute-forcing anything. It stores customer and employee PII, internal system URLs, and — in many deployments — session-related data or API credentials. Compromising one can hand an attacker lateral-movement groundwork without ever touching the network's defended perimeters. That is precisely why a breach in this category belongs on every helpdesk operator's risk register, not just the incident response team's radar.
Self-hosting shifts that risk directly onto the operator. There is no managed vendor perimeter to absorb the update cycle; when the patch window is open, closing it is the operator's responsibility. This general pattern applies to IT teams anywhere that run open-source tooling on their own infrastructure, including organisations in Hong Kong that self-host helpdesks or ticketing systems rather than buying a managed service. Note that the DIVD incident has not been reported as affecting organisations in Hong Kong; the relevance here is the pattern, not a confirmed local compromise.
What administrators should do now
- Confirm the deployment: Is Zammad self-hosted or SaaS, and exactly which version is running?
- Check Zammad's official advisories and release notes for fixes tied to the reported zero-days; do not rely on secondary summaries.
- Limit exposure while the picture is unclear: restrict public access behind a VPN or allowlist, disable open registration, and review web-server logs for anomalous requests.
- Review access logs for new administrator accounts, unusual ticket exports, or unexpected API calls.
- Rotate secrets the system could expose: admin passwords, session secrets, API keys, and anything tied to reset or notification flows.
- Assess blast radius if you suspect compromise: reset-link exposure, PII access, internal URLs harvested from tickets, and any credentials users pasted into support threads.
- Preserve evidence before remediation if an incident response path is triggered.
DIVD publishing its own breach details gives the rest of us something unusual in this space: a disclosure organisation operating with the same transparency it expects from vendors. As CVE identifiers, affected versions, and patch guidance emerge, that is where administrators should look — and this story should be updated to reflect them rather than restated with speculation.
如果你自行託管（self-host）Zammad —— 或任何同類型的開源 helpdesk —— 這個星期就要確認清楚自己運行的是哪個版本，以及有哪些人可以接觸到它。
根據 BleepingComputer 的報道，荷蘭漏洞披露機構 DIVD（Dutch Institute for Vulnerability Disclosure）表示，其自身網絡遭到入侵，原因是 Zammad —— 這款開源 ticketing system —— 存在兩個 zero-day 漏洞的漏洞鏈。DIVD 的成立宗旨是為其他機構協調漏洞披露，這次它自己成為了受害者。
選擇公開披露事件本身值得注意。這意味著一家運作自身基礎設施的安全機構，選擇將自家被入侵的情況記錄並公開，而不是靜靜地封鎖處理 —— 為整個生態系統提供了一本部分可行的操作手冊，即使技術細節仍不完備。
「AI 驅動」的說法出自 DIVD，尚未獲獨立佐證
DIVD 將這次入侵描述為 AI-driven。這個定性 —— 經 BleepingComputer 報道轉述 —— 是一家機構對自身事故的評估；它尚未獲獨立佐證，而且已審閱的材料並沒有指明這個標籤究竟指的是什麼 —— 是 AI 協助的偵察與目標選擇，還是入侵全程使用的攻擊者工具。讀者應將此描述視為單一機構的歸因，而非已確立的技術結論。
目前仍不清楚的事項
已報道的材料沒有列出 CVE 編號、受影響的 Zammad 版本，或修補狀態。截至本文章於 2026 年 9 月 30 日刊出之日，這些空缺在原始報道中仍然存在 —— 對於任何補上這些空缺的二手摘要，應保持懷疑。對管理員而言，實際後果很簡單：目前你不能假設自己已打上補丁，同樣也不應在未查閱 Zammad 官方 advisories 及 release 渠道之前，假設自己不受影響。
為何 helpdesk 是高價值目標
Ticketing system 不只是接收用戶投訴的隊列。它索引了內部存取權限。它承載著密碼重設流程，讓攻擊者毋須暴力破解便可取得帳戶接管（account takeover）所需的材料。它儲存了客戶與員工的 PII、內部系統 URL —— 在許多部署中，還有 session 相關數據或 API 憑證。攻陷一個 helpdesk，就能為攻擊者奠定 lateral movement（橫向移動）的基礎，甚至毋須觸及網絡中受防護的外圍防線。正因如此，這一類型的入侵必須列入每一位 helpdesk 營運者的風險登記冊（risk register），而不只是事故應變團隊的雷達範圍。
自行託管會把這項風險直接轉移到營運者身上。沒有託管供應商的外圍防線來吸收更新週期；當補丁窗口打開時，關閉它的責任在營運者。這個普遍模式適用於世界各地在自有基礎設施上運行開源工具的 IT 團隊，也包括香港一些選擇自行託管 helpdesk 或 ticketing system、而非購買 managed service 的機構。需要注意的是，DIVD 事件目前沒有報道指影響香港的機構；這裡的相關性在於模式本身，而非已確認的本地入侵。
管理員現在應做的事
- 確認部署方式：Zammad 是自行託管還是 SaaS？正在運行的確切版本是什麼？
- 查閱 Zammad 官方 advisories 和 release notes，尋找與報道中的 zero-day 相關的修復；不要依賴二手摘要。
- 在形勢未明期間限制暴露面：將公眾存取限制於 VPN 或 allowlist 之後，停用開放註冊，並檢查 web server 日誌中有無異常請求。
- 審查存取日誌，留意新增的管理員帳戶、異常的 ticket 匯出，或預期以外的 API 調用。
- 輪換系統可能外洩的 secrets：管理員密碼、session secrets、API keys，以及任何與密碼重設或通知流程相關的憑證。
- 評估 blast radius（影響範圍）：如懷疑已被入侵，應評估密碼重設連結的外洩情況、PII 存取、從 ticket 中收集到的內部 URL，以及用戶貼在 support 討論串中的任何憑證。
- 在啟動 remediation 前保全證據，前提是已觸發事故應變程序。
DIVD 公布自身入侵的詳情，為業界帶來了一份難得的範例：一家披露機構以它對供應商的同樣透明度運作。隨著 CVE 編號、受影響版本及修補指引陸續浮現，管理員應以這些官方資訊為準 —— 本報道應據此更新，而不是以猜測重述。