AI agent exploits Zammad zero-days in DIVD breach: What we know and how to detect it

This incident is currently under active investigation. The information in this blog is based on the information accessible as of the date of this blog, therefore the investigation information is likely to evolve.

On September 21, 2026, an agentic threat actor (ATA) breached the Dutch Institute for Vulnerability Disclosure (DIVD), a volunteer nonprofit that finds exposed systems on the internet and warns their owners. The ATA gained access by chaining two previously unknown vulnerabilities in the Zammad helpdesk platform, CVE-2026-102489 and CVE-2026-102490, and went from a hijacked session to root access in seconds.

According to the DIVD, the organization noticed suspicious activity, opened an investigation, and realized it had been hacked. The organization described the ATA as "loud and very, very messy," likely because AI agents are non-deterministic, choosing each action in succession at machine speed. That noise creates ample detection opportunities for security teams. Additionally, just as the Sysdig Threat Research Team (TRT) has seen from ATAs like JADEPUFFER, the AI agent behind the DIVD breach left comments in the code explaining its actions and reasoning. This noise is what allowed the DIVD to identify the breach within a day; however, due to the speed of the attack, even that was too late.

While this agent may have been poorly trained and configured, it was still able to accomplish its task by moving from the helpdesk software to the DIVD system and exfiltrating data. It is unclear how many confirmed Zammad users are impacted by these zero-days, but according to its website, there are over 2,000 customers and 55,000 users. This blog details what we know about how the intrusion unfolded and how security teams can detect and combat the next one, at speed, without knowing the CVE.

What happened at DIVD?

On October 1, 2026, DIVD confirmed that the breach led to data exfiltration. This is an ongoing investigation, and the organization’s understanding of the incident will likely continue to evolve.

The timeline below comes from the case files DIVD opened for the breach and the vulnerabilities:

Date

Activity

September 21

The attacker first gained access to DIVD systems

September 22

DIVD detected the intrusion, blocked access to all systems in its data center, and started a forensic investigation with Merlon Security.

September 22 to 23

DIVD analyzed and reproduced the vulnerabilities.

September 24

DIVD disclosed the breach to the Dutch data protection authority and the National Cyber Security Centre. DIVD also publicly announced the breach and disclosed the vulnerabilities to Zammad.

September 26

DIVD scanned for publicly exposed Zammad instances and began notifying vulnerable organizations.

September 29

DIVD published the case files and the two CVE records.

The vulnerabilities

Zammad is a widely deployed open source helpdesk software. DIVD identified both vulnerabilities in the software while investigating the breach with Merlon Security. The vulnerabilities were not disclosed prior to being used against DIVD, and have been characterized as zero-days.

CVE-2026-102489

• A remote code execution (RCE) flaw affecting versions 6.3.0 to 6.5.4. It is also present in versions 7.0.0 to 7.1.3, but is not exploitable due to specific environmental conditions. Impact on versions before 6.3.0 is unknown.
• Scored as a high-severity vulnerability with a CVSS score of 8.7. It’s a low-complexity vulnerability to exploit that does not require privileges, and because Zammad is an internet-facing web application, it is exposed at the web level and reachable over the publicly exposed internet.

CVE-2026-102490

• A local privilege escalation (LPE) flaw affecting all versions from 1.5.0 to 7.1.0-alpha.
• Scored as a high-severity vulnerability with a CVSS score of 8.5. It’s a low-complexity vulnerability to exploit that requires local access and minimal privileges.

Chained CVEs

• The RCE is exploitable only on versions 6.3.0 to 6.5.4, so the chain applies to that range.
• Scored as a critical severity vulnerability with a CVSS score of 9.4.

Attribution

As of the publication of this blog, no human operator has been tied to the ATA, nor has any group claimed responsibility. DIVD stated on LinkedIn that the agent read and exfiltrated data, but the exact purpose and impact of the attack are only just beginning to come to light as we learn more about the stolen data.

The agent's playbook

The DIVD already identified the attacker as an “autonomous AI agent,” and multiple pieces of evidence support that this was not a human-run campaign.

Features that distinguished the operation include:

• Autonomous, non-deterministic decisions: The attack chain was not pre-planned. Instead, the ATA chose its next step after every action, at machine speed.
• Self-documenting scripts: The agent explained its decisions in its script comments, which is common practice for machine-readability. Some of these comments described the actions as harmless; for example, "no phishing" and "no spam."
• Self-interference: The agent’s password spraying disrupted its own man-in-the-middle (MitM) attack.
• Poorly executed attack path: The attack was loud and messy, but the task was still ultimately accomplished. An agent will do what it takes to complete a task, regardless of the mess it makes and how brash it is. A human’s attack path and scripts are often quite the opposite: cleaner and more evasive.

Stage 1: Initial access via CVE-2026-102489

The ATA gained initial access via the RCE zero-day vulnerability CVE-2026-102489, which DIVD described as a session hijack that led to code execution as the zammad service user.

What's detectable?

The Zammad application process (Rails, Puma, and its worker children) should not spawn an interactive shell, download tools, or open outbound connections to hosts it hasn’t contacted before. If you profile what the zammad user normally executes, the first command the agent runs will stand out. To hunt for session hijacking, check for a session used from a new source address shortly after login, and for requests that skip the expected login flow.

Stage 2: Privilege escalation via CVE-2026-102490

The ATA chained the second zero-day vulnerability, CVE-2026-102490, with the first and gained root access for the zammad user.

It is important to note that a host that blocks the first vulnerability is still exposed to this flaw by attackers who are able to find local execution access another way. According to DIVD, the path from hijacked session (stage one) to root (stage two) took seconds.

What's detectable?

A service account on a host should never change its effective user ID to root; that’s a high-fidelity signal. On Linux, watch for setuid-family calls from the zammad user, new root-owned child processes under the application tree, and writes to privileged paths by that account. The following are open source Falco rules for privilege escalation and shells spawned by service accounts that cover these behaviors:

• Launch Privileged Container
• Non sudo setuid
• Set Setuid or Setgid bit
• Change thread namespace
• Potential Local Privilege Escalation via Environment Variables Misuse
• sudo potential privilege escalation

Stage 3: Credential attacks

Once the ATA had root-level access, it ran password spraying and a MitM attack, but it is currently unclear which systems or accounts these attacks targeted. However, due to the presumably untrained nature of this agent, the password spraying disrupted its own MitM attack, adding to the noisy nature of this particular operation.

A helpdesk host is typically a concentration of secrets, which is why Zammad was a valuable target. It stores database credentials, mail and API tokens, and API keys for every system the support team touches. Root access exposes all of them at once.

What's detectable?

Look for mass reads of configuration and credential files, bursts of failed authentications against many accounts from one source, and find or grep sweeps across the filesystem by processes outside the baseline. Runtime visibility at the syscall level can see each of these, regardless of what the agent calls itself.

Stage 4: Data access and exfiltration

Compromising Zammad was a launch point for the agent to reach other services and move data, in this case DIVD. Network segmentation and DIVD’s incident response actions stopped the agent from moving deeper into their environment. Following the identification of the breach, DIVD also cut access to every system in its data center. As of October 1, the investigation is still underway, but DIVD confirmed the following data was affected during preliminary analysis:

• Data confirmed exfiltrated: Volunteers' DIVD email addresses.
• Possibly exfiltrated: Volunteers' contact details.
• Entry point, with signs of compromise: The CSIRT ticketing system, with every email sent to the CSIRT mailbox and every reply, but DIVD believes it was only partially extracted. This information could include follow-up requests on scan data (including IP addresses of vulnerable systems), vulnerabilities reported, and extracts of credential dumps with masked passwords.
• Other signs of compromise: The project support environment (Jira and Confluence) and system data on IT systems that support DIVD's operations.
• Ongoing investigations: Google Workspace (office and administration), HR systems, IT support systems including the helpdesk, Slack, source code in GitHub and GitLab, and the sensitive research data DIVD holds, such as lists of vulnerable systems, fingerprints, de-weaponized PoCs, zero-day vulnerability details, and leaked credential dumps.
• Data with no known impact: Accounting information, bank accounts, and initial CSIRT notifications.

The confirmed stolen data also opens the possibility of someone impersonating a DIVD volunteer. Organizations should be on high alert for operations such as social engineering or phishing as a result.

What's detectable?

Look for outbound connections from the helpdesk segment to destinations it has never contacted, large or unusual uploads, and new tooling written to temporary directories and executed. A default-deny egress policy for the helpdesk segment turns exfiltration from a quiet event into a blocked event.

Detection and mitigation for the Zammad zero-day vulnerabilities and ATAs

Upgrade or take Zammad offline

Upgrade to Zammad version 7.0.0 or later, or take the instance offline altogether. Those versions are not exploitable, but are still at risk for the LPE flaw. Watch Zammad security advisories for a fixed build and monitor your environment for anomalous behavior by the zammad user in the meantime, if you do not take the instance down.

Additional guidance and indicators of compromise are available here: https://csirt.divd.nl/cases/DIVD-2026-00015/.

Isolate the helpdesk

Put the application in its own network segment with default-deny egress and tightly scoped access to internal services. A compromised helpdesk host should not be able to reach anything else. Segmentation helped limit the agent’s reach at DIVD.

Preserve evidence, then hunt

Keep /var/log/zammad and /var/log/nginx before rebuilding anything. Run DIVD's script against them to find any indicators of CVE-2026-102489 exploitation. A clean result does not equal a clean host, so also look for unfamiliar processes and files. Treat any sign of exploitation as full host compromise because the attacker had root access. Rotate every credential stored on or reachable from the host.

Detect on behavior, not signatures

A zero-day has no signature. A service account spawning a shell, escalating to root, or reaching unfamiliar destinations does not need one. Runtime detection for privilege escalation, shells in application processes, and anomalous outbound traffic covers the stages above without knowing the CVE.

Plan for machine-speed response

An agent that reaches root in seconds does not wait for your ticket queue. Pre-authorize automated containment for high-fidelity alerts, such as killing the process or isolating the host, and rehearse the datacenter-wide cut-off DIVD used.

Sysdig’s 555 Benchmark for Cloud Detection and Response sets the bar and encourages organizations to detect and respond to cloud attacks faster than attacks can complete them.

Conclusion

There were no stolen credentials this time. The attack only needed two zero-day vulnerabilities and an AI agent.

DIVD is a volunteer security organization whose job is finding and reporting exposed systems, and yet it still learned of the breach after it was too late. Fortunately, this ATA was noisy, which likely helped the DIVD incident response team identify it, and segmentation kept the agent from moving deeper into the environment and exfiltrating more data.

Agents move fast, and a better-built agent may make less noise, but the behaviors they produce don’t change. A service account spawning a shell, a process escalating to root, and unfamiliar outbound connections all look the same whether the exploit is a known CVE or a zero-day and whether the attacker is a human or an ATA.

It’s a case for runtime threat detection and segmentation. Detecting them in real time exposes an attacker who reaches root in seconds and works around the clock, and segmentation contains it. You need both to defend against a threat that acts at machine speed.

As you prepare your organization to defend against agentic threat actors, ask yourself three questions today:

• Would you know within seconds if a service account on your hosts spawned a shell or gained root access?
• Would that alert reach a person, or trigger an automated response, before the ATA finishes its next step?
• Could you cut off a network segment without taking the business or its critical applications down?

If the answer to any of them is no, your goal is to work toward automated runtime detection and response before the next zero-day vulnerability arrives.