Zammad Was Hit by an AI-Powered Zero-Day Attack — Two Bugs Reached Root
- The Mess: A Dutch vulnerability research organization was breached through two Zammad zero-days. DIVD says an agentic AI attacker chained them to hijack sessions, execute code and reach root in seconds.
- The Damage: A compromised helpdesk server can become a launchpad for data theft, lateral movement and access to other internal services.
- The Fix: If you run Zammad, upgrade to the current Zammad 7 release immediately and treat exposed systems as potentially compromised.
Zammad is supposed to be the boring part of infrastructure: tickets, support requests, internal workflows and customer conversations.
Instead, it became the front door for an intrusion into the Dutch Institute for Vulnerability Disclosure (DIVD), an organization whose entire business is finding security flaws before criminals do.
According to DIVD, attackers first gained access to its infrastructure on September 21, 2026. The organization initially described the intrusion as an agentic AI-powered attack. The later investigation identified two previously unknown Zammad vulnerabilities, CVE-2026-102489 and CVE-2026-102490, as the initial access and privilege-escalation chain.
That makes this incident particularly uncomfortable.
The security researchers were not breached through some exotic kernel exploit or obscure embedded device.
They were breached through their ticketing system.
The first bug: remote code execution
CVE-2026-102489 is a remote code execution vulnerability affecting specific Zammad releases.
DIVD describes exploitation in Zammad 6.3.0 through 6.5.4, where an attacker can achieve code execution as the Zammad service user. The vulnerability can also result in session leakage.
DIVD rates the vulnerability at CVSS 8.7 on its own.
The important part is what happens next.
Code execution as a low-privileged service account is not necessarily the end of the attack. In a properly isolated application, the attacker should hit another security boundary.
In this case, DIVD says the second vulnerability provided exactly the missing step.
The second bug: from Zammad user to root
CVE-2026-102490 is described by DIVD as a local privilege-escalation vulnerability.
The vulnerable local Zammad account can allegedly escalate privileges to root.
That changes the situation completely.
An attacker who starts with remote code execution as the application user no longer needs to fight the operating system from the outside.
The chain becomes:
Remote access → Zammad code execution → Zammad user → privilege escalation → root.
DIVD says the two vulnerabilities together produced a CVSS 9.4 critical chain.
The CVE record for CVE-2026-102490 currently describes affected Zammad versions from 1.5.0 up to 7.1.0-alpha and identifies Linux and Docker as affected platforms.
There is an important caveat.
Zammad publicly disputes parts of the disclosure.
Zammad disputes the second vulnerability
Zammad says it received information about CVE-2026-102489 earlier and considers current Zammad 7 releases protected against practical exploitation of that issue. The company says the hardening changes are included in Zammad 7.2.0.
The vendor also says it has not received the technical details of CVE-2026-102490 from DIVD and therefore cannot independently verify its scope or affected versions.
That means administrators are currently dealing with two different pieces of information.
DIVD says the vulnerabilities were used in the compromise and recommends upgrading to Zammad 7 or taking the installation offline.
Zammad says CVE-2026-102489 is not exploitable in current versions and that it has not received enough technical information about CVE-2026-102490 to verify the claim.
For defenders, that disagreement does not make an exposed Zammad server less interesting.
It makes incident response more important.
The AI part is the real story
DIVD says the attacker used an agentic AI system during the intrusion.
The organization reported that the agent operated autonomously, selected its next actions and moved through the environment without conventional human direction.
After obtaining access through Zammad, the attacker was able to execute code, escalate privileges and access additional services.
DIVD says the complete chain happened in seconds.
That is the part traditional vulnerability scoring does not capture very well.
A vulnerability does not need to become technically more powerful when an attacker adds automation.
The attacker simply needs to remove the waiting time between individual steps.
Reconnaissance.
Exploit.
Credential or session theft.
Privilege escalation.
Discovery.
Lateral movement.
Data collection.
Exfiltration.
An automated agent can potentially execute those decisions much faster than a human operator.
In the DIVD incident, investigators also found information that allowed them to reconstruct how the AI-driven attack behaved.
The attackers got data out
DIVD says the attackers reached other services after compromising the Zammad system.
The organization later confirmed that volunteer information was exposed, including DIVD email addresses and potentially contact information. The exact scope of the compromised data was still under investigation.
That creates another problem.
An email address belonging to a vulnerability researcher is not just another database field.
It can become useful for phishing, impersonation, social engineering and targeted attacks.
Once attackers know who works in security research, they also gain a much better map of potential targets.
CISA is treating the bugs as exploited
Both CVE-2026-102489 and CVE-2026-102490 have been added to the Known Exploited Vulnerabilities ecosystem, with remediation deadlines reported for October 5, 2026.
That matters because this is not a theoretical vulnerability report sitting in a database waiting for someone to publish a proof of concept.
There is an actual incident behind the disclosure.
The DIVD timeline says the malicious actor first accessed its systems on September 21. The organization detected suspicious activity the following day and moved into incident response.
DIVD subsequently scanned for vulnerable Zammad installations and began notifying potentially affected owners.
Network segmentation stopped the worst part
There is one piece of good news in the incident.
DIVD says network segmentation and incident-response actions prevented the attackers from moving deeper into the environment.
That is exactly why application security cannot be treated as a substitute for network security.
A vulnerable internet-facing application is eventually going to become somebody’s problem.
Segmentation determines how large that problem becomes.
If the compromised application can talk to every database, authentication server, backup system and management interface in the organization, one RCE can turn into an infrastructure-wide incident.
If it is isolated, the attacker has fewer places to go.
What Zammad administrators should do
First, identify every Zammad instance exposed to the Internet.
Do not assume that the server is safe because nobody has reported an obvious compromise.
Second, determine the exact Zammad version.
DIVD recommends upgrading to Zammad 7. Zammad itself recommends moving to 7.2.0 and keeping older unsupported releases out of production.
Third, investigate the host.
Look for unexpected processes, modified application files, new users, suspicious SSH activity, unusual outbound connections and evidence of command execution under the Zammad account.
Fourth, investigate sessions and credentials.
If an attacker had access to application sessions or executed commands as the Zammad user, assume that secrets accessible from the host may need to be rotated.
That includes database credentials, API tokens, service credentials and any secrets stored in configuration files.
Finally, inspect adjacent systems.
The DIVD incident demonstrates why the application itself cannot be the end of the investigation.
The attackers reportedly reached additional services after compromising Zammad.
Bugstoday opinion
This is the kind of incident that should make defenders uncomfortable.
Not because AI magically invented a new class of vulnerability.
The bugs were still ordinary security failures: remote code execution followed by privilege escalation.
The difference is speed.
An attacker that can autonomously discover what to do next can turn a multi-stage intrusion into a sequence of machine-speed decisions.
Zammad also exposes another uncomfortable problem: when researchers and vendors disagree about a vulnerability, administrators are left with uncertainty at exactly the moment when they need precise technical information.
The practical answer is simple.
If you run an exposed Zammad instance, do not wait for the argument to finish.
Patch it, isolate it and investigate it.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- DIVD CSIRT — DIVD-2026-00014 incident case
- DIVD CSIRT — DIVD-2026-00015 Zammad vulnerability case
- DIVD CSIRT — CVE-2026-102489
- CVE.org — CVE-2026-102490
- CISA Known Exploited Vulnerabilities Catalog
- Zammad Security Statement — CVE-2026-102489 / CVE-2026-102490
