Zammad Zero Days: AI Agent Got Root in Seconds, DIVD Says

DIVD spends its days scanning the internet for vulnerable systems and warning the people who own them. On September 24 it had to write a different kind of notice. "It took us (almost) seven years but we can now say that we're the hackers that got hacked," the volunteer run nonprofit wrote in a blog post.

Six days later it named the way in: two unknown bugs in Zammad, the open source helpdesk it ran. Its incident case file says "the hackers got in via two 0-day vulnerabilities in Zammad," and opens with a blunter line: "DIVD got hacked through AI agents."

Key Takeaways

• CVE-2026-102489 is a session hijack flaw in Zammad 6.3.0 to 6.5.4 that leads to remote code execution as the zammad user, and DIVD scores it 8.7 under CVSS v4.0.
• CVE-2026-102490 lets the local zammad user escalate to root, its CVE record says it affects "All versions of Zammad including the latest alpha," and chaining the two raises the score to 9.4.
• DIVD says an AI agent used the chain against DIVD's own network on September 21, 2026, reached root "in seconds," and exfiltrated data before network segmentation and incident response stopped it.
• DIVD's Zammad case file tells admins to upgrade to version 7 or take the instance offline, and says Zammad is still "working on a fix."
• Zammad had published no advisory for either CVE by the morning of October 1, 2026, and the AI agent account rests on DIVD's own statements.

What Is Zammad?

Zammad is an open source helpdesk and ticketing system from Zammad GmbH that pulls customer email and chat into one queue of tickets. The vendor's customer page counts "2,000+ Zammad Customers" and "55,000+ Zammad Users."

It runs self hosted or as a hosted service. DIVD's CVE records list the affected platforms as Linux and Docker. We found no statement from DIVD or Zammad on whether the hosted service was exposed.

What Are CVE-2026-102489 and CVE-2026-102490?

They are a remote code execution bug and a local privilege escalation bug in Zammad, published on September 30, 2026 by DIVD, which is itself a CVE numbering authority.

• CVE-2026-102489: "a session hijack vulnerability that leads to remote code execution as the zammad user." DIVD scores it 8.7 (high) with the vector AV:N/AC:L/AT:N/PR:N/UI:P: reachable over the network with no account needed.
• CVE-2026-102490: a flaw that lets "the local zammad user" escalate privileges to root. Alone it scores 8.5, because it needs local access first.

Each record carries a second score for the chained scenario: 9.4, critical. That is the number the NVD entry shows for both.

Two details in the vector matter to defenders. UI:P means passive user interaction, which the CVSS v4.0 specification defines as limited, involuntary interaction by a targeted user. In plain terms, the hijack needs a targeted user to do something ordinary, and DIVD has not said what. DIVD also marks both bugs as automatable and already attacked.

No root cause is public. The CVE titles call the bugs an "Undisclosed RCE" and an "Undisclosed LPE." The records credit five researchers from Merlon Security, the firm helping with DIVD's forensics, alongside DIVD's own team.

Which Zammad Versions Are Affected?

The code execution bug is exploitable in Zammad 6.3.0 through 6.5.4, and the privilege escalation bug is listed from 1.5.0 up to 7.1.0-alpha, according to DIVD-2026-00015:

• 6.3.0 to 6.5.4: vulnerable to the session hijack and remote code execution.
• 7.0.0 to 7.1.3: the same flaw is present "but not exploitable due to environment conditions."
• 1.5.0 to 7.1.0-alpha: vulnerable to the escalation from the zammad user to root.
• Before 6.3.0: the CVE record marks the code execution bug as status unknown, which is not the same as safe.

The 6.x range is wider than it looks. Zammad's release list dates version 6.3 to April 17, 2024 and 6.5.4 to April 8, 2026, and 6.5.4 is the newest stable 6.x tag in Zammad's GitHub repository. That is almost two years of releases, ending with the last 6.x build. As of October 1 there is no fixed 6.x release to move to, which is why DIVD's recommendation reads simply "Upgrade to Zammad version 7."

Three loose ends remain in the record:

• The case file marks patch status as "Available," while its text says DIVD reported the issue "to Zammad who are working on a fix."
• Upgrading to version 7 removes the exploitable entry point. By DIVD's own description it does not remove the root escalation, so any other bug that yields code execution as the zammad user would find the same path up.
• Neither record mentions Zammad 7.2, released on September 23, one day before DIVD reported the flaws to the vendor.

How Did the Attack Unfold?

The attacker first reached DIVD's systems on September 21, 2026, and DIVD noticed and cut off its datacenter the next day, according to the two case files and DIVD's public updates.

• September 21: "First access by malicious actor on DIVD systems."
• September 22: DIVD becomes aware, blocks access to all systems in the datacenter, and starts a forensic investigation with Merlon Security.
• September 22 to 23: the DIVD team analyses and reproduces the vulnerability.
• September 24: DIVD reports it to Zammad. The same day it goes public and notifies the Autoriteit Persoonsgegevens, the Dutch data protection authority, plus the National Cyber Security Centre, and talks to the police.
• September 26: DIVD scans for publicly reachable vulnerable Zammad instances and begins notifying their owners.
• September 30: the CVE IDs and both case files are published.

That is three days from first access to vendor report, and nine to public CVE IDs.

DIVD described the chain in a September 30 LinkedIn post quoted by BleepingComputer: "Used together, they allowed the attackers to hijack sessions, run code remotely and escalate privileges from the Zammad user to root, in seconds, due to the agentic part of this hack." The post continues: "From there they were able to access other services and read and exfiltrate data."

Which data left the network is not public. The incident case file lists an overview of "which data is compromised and which data is not" as planned for October 1. It had not appeared when we published.

What Does DIVD Mean by an AI Agent Attack?

DIVD means that software, not a person at a keyboard, chose each step of the intrusion, a conclusion it draws from how the attacker behaved. Its first statement said "the modus operandi indicates that this is an agentic AI powered attack."

A September 28 LinkedIn update, reported by BleepingComputer, gave the evidence in DIVD's words:

• "We could see the agent working automated, because after every action it decided the next step itself, at the speed of light and sloppy logic or pattern."
• The agent "has done some pretty dumb things, like polluting its own MITM attack with password spraying."
• The agent "is so overexplaining in its comments that it makes our job in reverse engineering a lot easier."

Keep the claim and the confirmation apart. DIVD has not published the logs or the agent's comments, and it has not named a model or framework. It says it sees "no link to any known public threat actors or involvement by a former volunteer." DIVD is at once the victim, a finder of the bugs, and the authority that issued the CVE IDs. Merlon Security shares the credit, and DIVD thanked NCSC-NL and NVISO Security for support, but we found no independent write up from any of them, and none from Zammad. This is a credible first party account that still awaits outside corroboration.

The tell is familiar, though. Sysdig identified the JadePuffer ransomware agent, which we covered in July, partly because its payloads were full of plain language reasoning left in code comments. Within a few months of each other, two unrelated defenders spotted a machine operator by the notes it wrote to itself. The two bug chain echoes July as well, when an autonomous agent breached Hugging Face by pairing two code execution flaws.

What Limited the Damage?

Network segmentation and a fast shutdown limited the damage, by DIVD's account. "Thanks to proper network segmentation and the actions of our IT and Incident Response Team after detection, we were able to stop the attackers from going deeper into our systems and network," the September 30 post says.

DIVD does not call that a clean escape. "Unfortunately some of the damage was already done," it adds, and the original statement commits the team to "assume breach until proven otherwise."

Speed cut both ways. DIVD says the chain ran in seconds, faster than any analyst could respond. It also called the attack "loud and very very messy," and it noticed the day after first access. Segmentation is the part of that defense that does not depend on reaction time: the helpdesk could not reach everything.

What This Means for Your Inbox

A helpdesk is a shared mailbox with a database behind it. Zammad's email account setup guide asks for an IMAP or POP3 host, a user and "Your account password," then an outbound mail server. Gmail and Microsoft 365 mailboxes connect through dedicated channels.

The same page carries a warning: "By default, Zammad will delete all emails in your inbox during the import process." Once mail is imported, the helpdesk may hold the only copy of what a customer wrote. An attacker with root on that server controls the application that stores those conversations and the credentials it uses to fetch and send mail.

People who write to support desks cannot see which software sits behind a support address. Two habits help. Keep passwords and card numbers out of support emails, even when support staff ask. And if a company you contacted discloses a helpdesk breach, treat any follow up that quotes your real ticket with suspicion, because stolen ticket history makes a convincing lure.

What Should Zammad Admins Do Now?

Admins should move every 6.x install to version 7 or take it offline, then check the logs for DIVD's indicator before trusting the server again.

• Find and version every instance. Anything from 6.3.0 to 6.5.4 is exploitable per DIVD, including internal and forgotten installs.
• Upgrade or unplug. DIVD's wording: "We advise all users of Zammad to upgrade to version 7 of Zammad or to take it offline." Kiteworks asked its own customers to do the same days earlier, covered in Kiteworks Zero Day Warning: Why It Told Customers to Unplug.
• Keep the logs. DIVD's check can only read logs that still exist, so copy /var/log/zammad and /var/log/nginx somewhere safe before you upgrade or rebuild. A clean run reports "NO INDICATORS in these logs," which says nothing about logs already rotated away.
• Run DIVD's log check. The case file mentions a verification script without linking it; a copy sits in DIVD's website repository. It scans those two directories by default, gzip archives included, for ERROR lines in files such as production.log and websocket.log that contain "Cookie"=> or @clients={. A hit prints INDICATORS FOUND -- SESSION MATERIAL IN ERROR OUTPUT and lists the cookies exposed. Read it before you run it.
• On a hit, assume root. DIVD has published no containment steps beyond its script's "Investigate further." Standard practice, and our advice rather than DIVD's, is to rebuild the host, then rotate every credential the instance held, starting with the mailbox passwords and OAuth grants behind its email channels.
• Segment the helpdesk. DIVD credits segmentation, together with its responders, for keeping the attacker out of the rest of its network.
• Watch for the vendor fix. When we checked on the morning of October 1, Zammad's GitHub security advisories listed nothing newer than August 25, 2026.

DIVD is still scanning for exposed instances and notifying owners. If a message from DIVD lands in your abuse or security mailbox this week, read it.