Zammad vulnerability: an AI agent hacks a help desk in seconds (FAQ)

2

chained zero-day flaws

seconds

from hijacked session to root

7.2.0

stable release Zammad recommends

On September 21, the attacker got in through DIVD’s internal Zammad. On the 22nd, DIVD detected the intrusion, cut access to every system in its data centre and started a forensic investigation with Merlon Security. On the 24th, it notified the Dutch data protection authority and the NCSC, went public and reported the flaws to Zammad. On the 29th, both CVEs were published. On October 1, DIVD confirmed data had been exfiltrated.

Because a ticketing tool concentrates secrets: database credentials, mail and API tokens, access to the systems the support team touches, plus the content of customer conversations. According to Sysdig, root access on that server exposes all of it at once. Zammad says it has more than 2,000 customers and 55,000 users.

CVE-2026-102489: session hijack leading to code execution as the zammad user. Exploitable on versions 6.3.0 to 6.5.4; also present in 7.0.0 to 7.1.3 but not exploitable in practice, according to DIVD (CVSS 8.7).

CVE-2026-102490: local privilege escalation from zammad to root, which DIVD describes as present from 1.5.0 to 7.1.0-alpha (CVSS 8.5). Zammad notes it cannot be exploited remotely on its own: an attacker needs a foothold on the server first.

Chained, DIVD scores them 9.4 (critical).

Speed. The agent picked each next step after the last one, at machine speed. DIVD described it as “loud and very, very messy”: it commented its own scripts, and its password spraying even disrupted its own man-in-the-middle attack. That noise allowed detection within a day, which was already too late. A better-built agent will make less noise.

According to the preliminary analysis reported by Sysdig: volunteers’ DIVD email addresses (confirmed exfiltrated), possibly their contact details, and part of the CSIRT ticketing system. Other environments (Jira, Confluence, Google Workspace, Slack, source code…) were still under investigation as of October 1. No group has claimed the attack. Direct consequence: expect phishing emails impersonating DIVD.

• Update to Zammad 7.2.0 (the vendor’s current stable release) or take the instance offline. Versions 6.5 and older no longer receive security fixes.
• Before rebuilding, preserve /var/log/zammad and /var/log/nginx and run DIVD’s detection script against them.
• Any sign of exploitation = full server compromise: rotate every credential and token stored on, or reachable from, that server.
• Isolate the tool in its own network segment with outbound internet traffic denied by default.

The sources we reviewed do not say whether hosted Zammad is affected: ask your provider. For any SaaS tool the lesson is the same: MFA on every account, API tokens limited to what is strictly needed, and no plain-text passwords in tickets. The same reflex applies to forgotten in-house servers, as we saw with Warlock and SharePoint.

A zero-day has no signature, but its behaviours do: a service account spawning a shell, becoming root or contacting an unknown destination. Those are the signals to watch continuously, with a fast response planned in advance (isolate the server, cut access). For another example of attackers using AI agents, see our article on the attempt against Library and Archives Canada.