Security Guides

#vulnerabilities #AI security #incident response #patch management #international

DIVD breach (two Zammad zero-days): what leaked and what organizations running Zammad should do

Dutch disclosure nonprofit DIVD was breached through two Zammad zero-days, with an AI agent driving the intrusion. What leaked and what Zammad operators should do.

Published 2026-10-05 Updated 2026-10-05 Last verified 2026-10-05 13 min read

For: organizations that run the Zammad help-desk software themselves, and organizations that received a vulnerability notification from DIVD (the Dutch vulnerability disclosure nonprofit) and corresponded with it. This article is based on DIVD's disclosures and the developer's statements and does not cover attack techniques.

Check whether this affects you

Your situation	What is relevant	What to do
You run Zammad on your own servers or in Docker	The two vulnerabilities (CVE-2026-102489, CVE-2026-102490)	Everything in "What organizations running Zammad should do today" below
You received a DIVD notification and exchanged emails with its CSIRT	DIVD asks you to assume the attackers may have that correspondence	Fix the reported vulnerabilities quickly. Verify any message claiming to be DIVD through another channel
You received a DIVD notification but never replied	According to DIVD, its initial notifications are not stored in this ticketing system	Confirm that the reported vulnerability has been fixed
You are a DIVD volunteer	DIVD email addresses confirmed taken; contact details possibly	Be careful with messages impersonating DIVD people

Verify messages claiming to be DIVD through another channel

DIVD warns that because volunteers' contact details may have been taken, it is now easier to impersonate DIVD people.

If a message that appears to come from DIVD asks you to open a file, enter login details or urgently change settings, do not act on it right away. Check with DIVD through the official contact listed on its case page.

What organizations running Zammad should do today

Check your version and update to 7.2.0

The developer recommends updating to Zammad 7.2.0, the current stable release (7.2 was released on September 23, 2026).

Versions 6.5 and older are already out of the developer's support. DIVD advises taking the instance off the internet if you cannot move to version 7. If you are on 6.x, make this your first task.

Keep watching for a fix for CVE-2026-102490

The second flaw, CVE-2026-102490, lets the user that runs Zammad gain administrator (root) privileges. The developer says it cannot be exploited remotely on its own and that an attacker would already need access to the server.

As of October 5, 2026, no fixed release for this flaw has been confirmed. The developer points users to its GitHub security advisories, so keep checking them after you update.

Review what you expose to the internet

If only your own staff use Zammad, put it behind a VPN or restrict the source IP addresses so it cannot be opened directly from the internet.

If customers need it to submit requests, consider whether at least the admin and agent screens can be limited by source address. The less you expose, the smaller the impact when an unknown vulnerability turns up.

Look for signs of intrusion

On its case page, DIVD publishes a log-check script and indicators of compromise (IoCs). Use them to check your Zammad logs.

Also look for admin accounts or sessions you do not recognize, and for unfamiliar programs running on the Zammad server. Be especially thorough if you had a 6.x instance exposed to the internet.

If you suspect intrusion, change the keys and passwords stored in Zammad

Because CVE-2026-102490 leads to administrator privileges, if you were breached, assume every credential on that server has been read.

Rotate the API tokens stored in Zammad, the passwords of the mailboxes it receives requests from, and the keys used for integrations with other services, and invalidate user sessions. Rebuilding the server itself is the more reliable option.

The two vulnerabilities and the published scope

CVE-2026-102489: session hijacking (session fixation) that leads to running code as the user that runs Zammad (remote code execution). Per DIVD, exploitable in 6.3.0 to 6.5.4, and present but not exploitable in 7.0.0 to 7.1.3 due to environmental conditions. The developer says only 6.5 and older can be exploited and that the change is included in 7.2.0.

CVE-2026-102490: lets the Zammad user gain root privileges. Per DIVD, affects 1.5.0 through 7.1.0-alpha. The developer says it cannot be exploited remotely on its own; no fixed release confirmed as of October 5.

DIVD rates the severity of the two combined at 9.4 out of 10.

The two accounts differ in places, such as how the affected versions are described. Both agree that 6.x is at risk and that updating to 7.2.0 is recommended, so start there. How to decide which fixes come first is covered in CVSS, EPSS and KEV.

What happened (from DIVD's disclosures)

DIVD is a volunteer-run nonprofit in the Netherlands that looks for vulnerable systems on the internet and notifies their owners. It disclosed the breach on September 24 and has posted updates on its case pages (DIVD-2026-00014 and DIVD-2026-00015). The following is as stated by DIVD.

Sep 21, 2026
Unauthorized access begins.
Sep 22
Suspicious activity detected; access to all data-center systems blocked. The incident response team starts work with support from an outside forensics firm (specialists who investigate records to find the cause and scope).
Sep 24
Breach disclosed publicly. The Zammad vulnerabilities reported to the developer.
Sep 26
A limited disclosure of the vulnerabilities published; DIVD begins scanning for Zammad instances on the internet and notifying owners who may be vulnerable.
Sep 29
The two CVEs (CVE-2026-102489, CVE-2026-102490) published. DIVD says it sees no link to any known public threat actor.
Oct 1
Overview of the exfiltrated data published. The developer explains the scope on its community forum.
Oct 2
CISA adds both flaws to KEV (the list of vulnerabilities confirmed exploited). Deadline for US federal agencies: October 5.

Previously unknown Zammad vulnerabilities exploited

Confirmed

Exfiltration of volunteers' DIVD email addresses

Partial

Information extracted from the CSIRT ticketing system (scope under investigation)

No signs

Accounting systems and bank account (run by outside parties)

What was taken (from DIVD's data investigation overview)

Volunteers: DIVD email addresses confirmed exfiltrated. Contact details possibly exfiltrated
CSIRT ticketing system: Holds every email sent to the CSIRT mailbox and every reply. Only part was extracted. Anyone who corresponded with the CSIRT is asked to assume the attackers may have that information
May include: Follow-ups on scan data (including IP addresses of vulnerable systems), vulnerabilities reported through the CSIRT mailbox, extracts of credential dumps with masked passwords
Not included: DIVD's initial notifications are not stored in this system
Office cloud administration: Under investigation
Accounting and bank: Run by outside parties; no signs of compromise
Numbers: Not disclosed
Attacker: No link to any known public threat actor. Whether DIVD was targeted or hit opportunistically is not confirmed
Reports: Reported to the Dutch data protection authority (AP) and the National Cyber Security Centre (NCSC); police consulted

Way in: two previously unknown Zammad vulnerabilities

CVE-2026-102489 (run code) → CVE-2026-102490 (gain root)

↓ September 21–22, 2026

DIVD CSIRT ticketing system (Zammad)

Holds every email to the CSIRT mailbox and every reply. Only part was extracted

↓ Data taken, or possibly taken

Correspondence with the CSIRT

IP addresses of vulnerable systems, reported vulnerabilities → fix the reported issues quickly

Volunteers' DIVD email addresses (confirmed) and contact details

Messages impersonating DIVD become easier → verify through another channel

Not included, or no signs of compromise

DIVD's initial notifications (not stored in this system), accounting systems and bank accounts

Two Zammad vulnerabilities were the way in, and part of the data in the CSIRT ticketing system was taken. What you should do depends on which data concerns you.

DIVD says network segmentation and the actions taken after detection stopped the attacker from going deeper into its network.

Why DIVD concluded an AI agent ran the intrusion

DIVD describes the post-intrusion activity as an "agentic AI-powered attack". The points it gives are these.

It looked at the result of each action and decided the next step itself
The attacker's scripts contained notes in which the agent justified its own actions
Going from exploiting the flaw to administrator privileges took seconds
It was fast, but its logic was sloppy and its activity was noisy

According to reporting by BleepingComputer, DIVD also said the agent made mistakes such as interfering with its own password-guessing attack. DIVD says the explanations the agent left behind let it reconstruct the intrusion in detail.

What DIVD's disclosures establish

The entry point was two unknown Zammad vulnerabilities
The post-intrusion activity is assessed as an AI agent's
Part of the information was taken
The attacker did not get past the network segmentation

What is not known

Who operated the agent
Which AI was used
Whether DIVD was targeted or hit opportunistically
The exact scope and number of records taken

Another case of an AI agent advancing an intrusion without waiting for human instructions is the Hugging Face intrusion of July 2026. That case involved an agent that escaped an evaluation environment; in this case, DIVD assesses that an attacker used an agent for the post-intrusion work. The wider picture of AI agents reaching websites is covered in AI agents reaching real websites.

For operators, the practical meaning is that the time between a flaw being exploited and the damage spreading gets shorter. What limited the damage at DIVD was network segmentation. Alongside faster updates, a layout where one compromised machine does not open the way to everything else pays off.

What organizations running ticketing systems should review

What leaked here was correspondence a security organization had received about other organizations' weaknesses. IP addresses of vulnerable systems and reports of still-unfixed vulnerabilities can serve an attacker as a list of next targets. A help-desk system gathers your own customers' and partners' information in the same way.

Treat the ticketing system as a system that holds important data

A help-desk system collects customer contact details, descriptions of problems, and sometimes passwords or configuration details. Classify it internally as a system holding important data, and give its updates and monitoring the same priority as your core systems.

Do not keep old tickets longer than needed

Set a retention period after which resolved tickets are deleted or moved elsewhere. For correspondence containing vulnerability reports, credentials or system configuration, consider a short deadline for deletion once the matter is closed.

Do not run versions that are out of support

According to both DIVD and the developer, the flaw used as the entry point can be exploited on the 6.x line, which the developer no longer supports. Help-desk systems tend to be installed once and then left behind on updates. Record the support end date in your inventory and plan the upgrade before it arrives.

Separate the ticketing server from your other systems

DIVD says its network segmentation stopped the damage from spreading. Make sure the help-desk server cannot freely connect to your other internal systems or admin interfaces. The approach is covered in The minimum security baseline for organizations.

Sources (public record)

The facts in this article come from the public sources below. Undisclosed attack techniques and the identity of the attacker are not speculated on.

DIVD, "DIVD-2026-00014" (incident overview and timeline, updated October 1, 2026) — csirt.divd.nl
DIVD, data investigation overview (DIVD-2026-00014) — csirt.divd.nl
DIVD, "DIVD-2026-00015" (the Zammad vulnerabilities, affected versions, log-check script) — csirt.divd.nl
DIVD, "CVE-2026-102489" — csirt.divd.nl / "CVE-2026-102490" — csirt.divd.nl
Zammad community forum (statements by the developer's staff, October 1, 2026) — community.zammad.org
Zammad release notes (7.2, September 23, 2026) — zammad.com / security advisories — github.com
CISA, Known Exploited Vulnerabilities Catalog (added October 2, 2026) — cisa.gov
Reporting: BleepingComputer, "Automated AI agent used to breach cybersecurity nonprofit DIVD" (September 29, 2026) — bleepingcomputer.com
Reporting: BleepingComputer, "DIVD says Zammad zero-days enabled AI-driven network breach" (September 30, 2026) — bleepingcomputer.com

Update history

2026-10-05: First version, based on DIVD's disclosures (through the October 1 update), the developer's statements (October 1) and CISA's KEV addition (October 2). DIVD's investigation is ongoing; this article will be updated when a fix for CVE-2026-102490 is published.

FAQ

QWhat is DIVD?

DIVD (Dutch Institute for Vulnerability Disclosure) is a volunteer-run nonprofit security organization in the Netherlands. It looks for systems exposed on the internet with known vulnerabilities and notifies their owners (vulnerability disclosure). It runs a CSIRT (a team that acts as the contact point for security incidents) for this work.

QWhat was leaked?

According to DIVD, volunteers' DIVD email addresses were confirmed exfiltrated, and volunteers' contact details may also have been. Part of the information in the CSIRT ticketing system was extracted. DIVD asks any organization or individual who corresponded with its CSIRT to assume the attackers may have that information. This may include follow-ups on scan data (including IP addresses of vulnerable systems), vulnerabilities reported to the CSIRT mailbox, and extracts of credential dumps with masked passwords. No signs of compromise were found in the accounting systems or bank account. As of October 5, 2026, the investigation is ongoing.

QWhat does it mean that an AI agent carried out the attack?

DIVD assessed that the post-intrusion activity was performed by an automated AI agent that looked at the result of each action and decided the next step itself. As evidence, it cites notes left in the attacker's scripts in which the agent justified its own actions. DIVD also describes the activity as fast but sloppy and noisy. Who operated the agent is unknown; DIVD says it sees no link to any known public threat actor.

QWhich Zammad versions are affected?

DIVD says CVE-2026-102489 is exploitable in 6.3.0 to 6.5.4 and is present but not exploitable in 7.0.0 to 7.1.3 because of environmental conditions, and that CVE-2026-102490 affects 1.5.0 through 7.1.0-alpha. On its community forum, the developer said CVE-2026-102489 can only be exploited on 6.5 and older, that 7.0 and later are not affected, and that the change is included in 7.2.0. For CVE-2026-102490, it said the issue cannot be exploited remotely on its own and requires existing access to the server; as of October 5, 2026, no fixed release has been confirmed. The two accounts do not fully match.

QI run Zammad. What should I do?

The developer recommends updating to 7.2.0, the current stable release. Versions 6.x and older are out of support, and DIVD advises upgrading to version 7 or taking the instance offline. Then review what is exposed to the internet, and use the log-check script and indicators of compromise (IoCs) published by DIVD to look for signs of intrusion. If you find suspicious traces, rotate the API tokens, mailbox passwords and other credentials stored in Zammad.

QWhat does it mean that the flaws were added to KEV?

KEV (Known Exploited Vulnerabilities) is the US Cybersecurity and Infrastructure Security Agency's (CISA) list of vulnerabilities confirmed to be exploited in the wild. CISA added both flaws on October 2, 2026, and required US federal agencies to act by October 5. It creates no legal duty for organizations elsewhere, but it is widely used to decide which fixes come first.