The investigation into the September breach of the Dutch Institute for Vulnerability Disclosure, or DIVD, has now identified the initial access path: attackers chained two previously unknown vulnerabilities in the open-source Zammad helpdesk platform and then used an agentic AI system to move through the compromised environment at machine speed. The two vulnerabilities are now tracked as CVE-2026-102489 and CVE-2026-102490. DIVD says the first can provide remote code execution in vulnerable Zammad environments and can be used in connection with session compromise, while the second allows a local zammad user to escalate privileges to root. Used together, the vulnerabilities gave the attacker a path from application access to complete operating-system control.

That changes the interpretation of the incident considerably. When DIVD first disclosed the breach, the most striking element was the behavior of the attacker after entry. Investigators described an AI-driven operation that was “loud and very, very messy,” leaving behind extensive evidence of how the agent evaluated the environment, selected actions, and decided what to do next. At that point, the initial vulnerability had deliberately not been disclosed. We now know that the entry point itself was serious, and the conceptual attack chain becomes: Zammad exposed to attacker → CVE-2026-102489 exploited → session access or remote code execution → attacker executes as Zammad user → CVE-2026-102490 exploited → root privileges obtained → AI agent discovers additional services → data accessed and exfiltrated → network segmentation and DIVD response prevent deeper movement.

This combination deserves attention because the AI agent did not need to discover some unprecedented new way of breaking computer security. It was given access through conventional software vulnerabilities. What changed was the speed and autonomy of what happened afterward. DIVD says the chained vulnerabilities allowed the attacker to move from exploitation to root-level access “in seconds” because of the agentic component of the intrusion. BleepingComputer reports that the attacker then accessed additional services and read and exfiltrated data from DIVD systems before network segmentation and incident-response actions limited further movement. The zero-days opened the door; the AI dramatically accelerated what the attacker could do once the door was open.

According to DIVD’s current advisory, CVE-2026-102489 affects Zammad versions 6.3.0 through 6.5.4 and can allow remote code execution as a Zammad user, with session leakage involved in the exploitation path. DIVD says the vulnerable code is also present in Zammad 7.0.0 through 7.1.3, although exploitation in those versions is prevented under the environmental conditions it analyzed. The exact technical details are being disclosed carefully because DIVD is simultaneously trying to identify and warn other exposed Zammad installations. That restraint is sensible because once a working exploit for a remotely reachable helpdesk platform becomes widely available, the vulnerability can quickly move from targeted exploitation into broad Internet scanning.

Helpdesk systems are particularly attractive targets because they are commonly Internet-facing by design and often contain far more sensitive operational information than organizations realize. Support tickets routinely include customer correspondence, uploaded attachments, internal troubleshooting notes, employee names, infrastructure details, logs, screenshots, software versions, temporary passwords, API tokens and configuration information. Compromise of a helpdesk platform can therefore provide both system access and an unusually useful intelligence repository. For a cybersecurity organization such as DIVD, that information may be even more sensitive because the ticketing environment can contain vulnerability-related communication and operational coordination.

The second flaw, CVE-2026-102490, provides local privilege escalation from the Zammad service account to root. DIVD currently lists the vulnerability as affecting Zammad versions from 1.5.0 through 7.1.0-alpha in its case information. This second stage is what makes the vulnerability chain substantially more serious. A web-application compromise limited to an unprivileged service account can still be damaging, but operating-system controls may restrict what the attacker can access. Root removes most of those boundaries. Once the attacker controls the operating system, they can potentially read application configuration, access database credentials, inspect authentication material, modify services, install persistence, capture secrets from other processes, tamper with logs, access locally stored data and use the server as a foothold for lateral movement. In simple terms, RCE gets the attacker onto the server; privilege escalation gives them the server.

The most unusual part of the attack remains what happened after exploitation. DIVD says the attacker used an agentic AI system capable of selecting subsequent actions without constant human direction. During the earlier disclosure, investigators described observing the agent analyze results and decide what to do next, while simultaneously making mistakes and generating substantial forensic noise. The AI reportedly performed reconnaissance, attempted multiple attack techniques, handled authentication activity and continued adapting its approach based on what happened. It was not flawless: it reportedly interfered with some of its own activity and left behind unusually clear explanations of what it was doing. But that may be the wrong standard for evaluating the threat. An offensive agent does not need to be better than an elite penetration tester; it only needs to be capable enough to perform routine post-exploitation work much faster than a human operator.

That difference changes incident-response timelines. A human attacker might need several minutes to inspect a compromised application, identify the operating system, enumerate privileges, search for credentials, test another vulnerability and investigate adjacent services. An AI agent can potentially perform many of those actions almost immediately and in parallel. The important security metric therefore becomes less about how intelligent the AI is and more about how much defender reaction time disappears. Traditional SOC workflows are frequently built around human processing: an alert fires, enters a queue, an analyst opens it, reviews telemetry, escalates the case and eventually containment is approved. That may be reasonable when attackers operate at roughly human speed. It becomes problematic when an autonomous system can progress from application compromise to root access and additional service discovery before the first alert has even been triaged.

The DIVD incident therefore reinforces an uncomfortable equation: machine-speed offensive action increasingly requires machine-speed defensive containment. That does not mean every anomaly should automatically disconnect production servers, because automated response can itself create outages. But organizations need clearly defined, high-confidence conditions under which systems can be isolated, identities revoked, sessions terminated or network access restricted before a human analyst completes the entire investigation.

One encouraging element of the DIVD incident is that the attackers did not move deeper into the network, according to the current public reporting. DIVD attributes this in part to its segmentation and incident-response actions. That provides a practical demonstration of why segmentation remains important even when perimeter defenses fail. A vulnerable Internet-facing application was compromised, root access was obtained and data was accessed, yet compromise of that system did not automatically translate into unrestricted access to everything DIVD operated. This is precisely what segmentation is supposed to accomplish. Security architecture should assume that eventually an application will contain a zero-day, credentials will be stolen, an administrator will make a mistake or an endpoint will become compromised. The question then becomes whether the attacker can move directly from that one failure into every other important system. The answer needs to be no.

The incident also highlights an architectural mistake many organizations make with ticketing and support systems. Helpdesk software is often classified as ordinary business software, when in reality it frequently contains extremely sensitive operational information. Organizations using Zammad or comparable ticketing systems should therefore consider them high-value Internet-facing infrastructure, not merely workflow applications. Self-hosted deployments deserve particular attention because self-hosting provides control over infrastructure and data while also transferring responsibility for patching, exposure management, hardening and monitoring to the operator. Security teams should know which Zammad instances they operate, which versions are installed, which are reachable from the Internet, what privileges the service account holds, what network segments the server can reach and whether the system can directly communicate with internal management services.

DIVD says it began scanning for publicly vulnerable Zammad instances on September 26 and is notifying affected organizations as part of DIVD case 2026-00015. The vulnerabilities are no longer hypothetical. They were used against DIVD on September 21, before public disclosure, making them known exploited zero-days. Other vulnerable systems therefore cannot safely assume the DIVD breach was the only exploitation. There is currently no evidence establishing widespread exploitation, but defenders should investigate rather than simply assume absence of compromise.

Upgrading is necessary, but patching alone is not enough. DIVD recommends that Zammad users move to the current Zammad 7 release or take vulnerable instances offline while remediation is performed. Administrators should verify the exact fixed build recommended by Zammad and DIVD rather than assuming that any release beginning with “7” is automatically safe, particularly because DIVD’s technical notes indicate that the vulnerable RCE code exists in some earlier 7.x builds even where exploitation conditions differ. More importantly, organizations running versions exposed during the zero-day period should treat remediation as patch plus compromise assessment, rather than assuming the incident is finished once the software is updated.

If the vulnerabilities were exploited before the update, the attacker may already have root-level access. Updating Zammad will not automatically remove persistence, rotate stolen credentials, invalidate sessions, restore modified system files, revoke added SSH keys, remove scheduled jobs, undo database changes or erase other malware. The patch closes the original door; it does not search the building. Organizations with potentially exposed Zammad servers should therefore examine more than application logs and review the full operating system for unexpected root-level process execution, new accounts, modified sudo configuration, new or altered SSH keys, new services, cron jobs, systemd units, unexpected binaries, changes under application directories and unusual outbound connections.

Authentication logs should also be reviewed for unusual Zammad sessions and session reuse. Because the initial vulnerability is associated with session compromise, unexplained authenticated activity may be especially relevant. Any locally accessible secret should also be considered potentially exposed after root compromise. Zammad servers may contain email credentials, database passwords, LDAP or Active Directory bind accounts, OAuth secrets, API credentials, SMTP configuration, cloud tokens and backup access. Incident response should therefore include credential rotation based on what was actually reachable from the compromised server. Otherwise organizations risk fixing the original vulnerability while leaving attackers with perfectly valid credentials obtained during the compromise.

Root access also turns logging into an evidence problem. Once an attacker gains root, local logs become less trustworthy because a privileged attacker can alter or delete evidence. Organizations should therefore rely wherever possible on remote log collection. Reverse proxy logs, firewall telemetry, SIEM records, identity-provider logs, NetFlow, DNS telemetry and external authentication logs may survive even if the Zammad host itself is modified. This incident is another strong argument for sending logs away from the system generating them. If the server being investigated is also the only place storing evidence about its own compromise, defenders have created an unfortunate single point of forensic failure.

The combination demonstrated by DIVD may represent a more important trend than either component alone. Zero-day exploitation has existed for decades, and automated exploitation has existed for decades. AI agents potentially provide a flexible layer between those two concepts. An attacker can provide an agent with a target, an initial vulnerability, a set of tools and an objective. The agent can then perform discovery and react dynamically to results, reducing the amount of specialist human interaction required after initial access. One experienced operator could theoretically supervise multiple concurrent intrusions instead of manually driving each shell, moving the bottleneck from “How many systems can the attacker manually operate?” toward “How many agents can the attacker supervise?”

DIVD’s earlier observations are useful precisely because the attacker’s AI appeared imperfect. It was noisy, made mistakes, sometimes pursued conflicting actions and left comments behind, yet the attack still succeeded. That should temper two competing exaggerations. The first is that AI hackers can autonomously compromise anything, which is unsupported. The second is that the AI was sloppy and therefore not a serious threat, which is equally misguided. The relevant combination is moderate competence plus enormous speed, persistence and scalability. That is enough to change defensive requirements.

The DIVD chain illustrates this particularly well: zero-day → RCE → local privilege escalation → root → additional service access → data exfiltration. According to DIVD, the agentic component compressed parts of that progression into seconds. A SOC cannot reasonably rely on an analyst seeing the first alert, reading the ticket, discussing it in a chat channel and manually deciding what to isolate if the attacker can complete several post-exploitation stages before that conversation begins. The future of high-confidence detection increasingly needs to include automated containment. The human remains responsible for the decision framework, but the machine may need to execute it.

The broader cybersecurity lesson from the DIVD breach is that AI did not eliminate conventional vulnerabilities; it depended on them. AI did not make network segmentation irrelevant; segmentation helped contain the intrusion. AI did not make logging irrelevant; its noisy behavior produced valuable forensic evidence. What AI changed was the tempo of the attack. The vulnerabilities gave the attacker capability, and the agent turned that capability into actions at a speed human defenders may struggle to match.

The full chain can therefore be summarized as: Internet-facing Zammad → zero-day RCE/session compromise → Zammad service account → zero-day privilege escalation → root → agentic reconnaissance and decision-making → service access → data exfiltration → segmentation and emergency isolation limit further spread. The incident contains two warnings. For Zammad users: patch immediately and investigate historical exposure. For everyone else: start measuring incident response in relation to machine-speed attackers, not only human-speed attackers.

The most consequential part of the DIVD incident may ultimately not be that an AI agent participated in a real-world breach. It may be that once the agent was given a valid path inside, seconds became enough time to turn one software vulnerability into a root-level intrusion.

The Dutch Institute for Vulnerability Disclosure (DIVD) says that the breach of its network was possible by exploiting a chain of two zero-day vulnerabilities in the open-source Zammad ticketing system. [...]

Source: DIVD says Zammad zero-days enabled AI-driven network breach via Bleeping Computer — published 30 Sep 2026.