al-ice.ai

The Ticket Queue Was the Way In: Two Zammad Zero-Days Took an AI Agent From Session Hijack to Root in Seconds

Agent & Supply Chain Security by al-ice.ai Editorial

Nine days after disclosing that an autonomous AI agent had breached its own network, the Dutch Institute for Vulnerability Disclosure has named the weapon: two previously unknown vulnerabilities in the open-source Zammad ticketing system, chained together to go from session hijacking to remote code execution to root. DIVD published the findings as case DIVD-2026-00015 on 30 September, with the case page updated again on 1 October. The CVEs are CVE-2026-102489 and CVE-2026-102490.

This is the follow-up to the breach DIVD disclosed on 24 September, in which the attacker moved autonomously — DIVD's own description was "loud and very, very messy" — and left behind explanations of its decisions detailed enough for the nonprofit to reconstruct the incident. What the new case adds is the entry point, and it is unglamorous: the support desk.

The chain, as DIVD documents it

  • CVE-2026-102489 — session hijack to RCE. Zammad versions 6.3.0 to 6.5.4 carry a session-hijacking flaw that leads to remote code execution as the zammad service user. DIVD notes the flaw is also present in 7.0.0 to 7.1.3 but is not exploitable there "due to environment conditions." The researchers were a joint DIVD–Merlon Security team led by Victor Pasman.
  • CVE-2026-102490 — local privilege escalation to root. Every Zammad version DIVD examined, from v1.5.0 through the v7.1.0 alpha, lets the local zammad user escalate to root. This is the second stage: once the agent had code execution as the service account, root was one more local bug away.

DIVD's timeline is precise: the vulnerabilities were abused against DIVD on 21 September, analysed and reproduced by the DIVD team on 22–23 September, reported to Zammad on 24 September, and followed by internet-wide scanning and victim notification starting 26 September. Only network segmentation and incident-response actions stopped the intruder from moving deeper, and the investigation is still open. Used together, the pair allowed hijacked sessions, remote code execution, and the climb from the Zammad user to root — with the agentic part compressing the whole sequence into seconds.

Why the support desk keeps being the front door

Ticketing systems are built to be reachable: they face users, ingest untrusted content all day, and usually run with enough privilege to be useful. Zammad describes itself as an AI-powered helpdesk, and BleepingComputer notes it claims more than 2,000 customers and 55,000 users, including De'Longhi, Amnesty International, and Nextcloud. A pre-authentication session flaw in software with that footprint is a skeleton key — and the LPE underneath means the service account was never the containment boundary anyone assumed.

The uncomfortable symmetry is that the victim here is the organisation that scans the internet warning others about exactly this class of exposure, and it still took a breach to find the bugs. DIVD is now doing to the Zammad population what it always does: actively scanning for publicly reachable vulnerable instances and alerting their owners, and it has published a log-check script so administrators can hunt its indicators of compromise in their own Zammad logs.

What to do

  • Upgrade to Zammad 7 or take the instance offline. That is DIVD's stated recommendation, verbatim. Note the nuance in the case file: 7.0.0–7.1.3 contains the 102489 code but is assessed as not exploitable, while 102490 spans all examined versions — so treat "upgrade to 7" as the floor, not the ceiling, and watch Zammad's own fix for the LPE.
  • Run DIVD's IoC log check before you patch. Patching closes the hole; it does not tell you whether an agent-shaped visitor already walked through it in seconds. DIVD's log-check script exists for exactly this question — use it first, especially on instances exposed to the internet around 21 September or earlier.
  • Assume internal tooling is the attacker's fastest path, not the slowest. Ticketing, monitoring, and IT-support apps sit at the intersection of network-reachable and trusted. Inventory yours the way an external scanner would — which is precisely what DIVD is doing to the Zammad fleet right now. The seven-minute Azure destruction run made the same point from the other side: once the agent is in, the debate is measured in seconds, and segmentation is the only control that fired here.
  • Rehearse for the disclosure, not just the patch. DIVD ran limited disclosure on 26 September, notified instance owners directly, and went public on the 30th — a textbook coordinated-disclosure sequence executed while itself being the victim. If your team runs internet-facing open-source infrastructure, that notification-to-publication playbook is worth having written down before you need it.

Sources: