AI-powered Agents Autonomously Exploit Chained Zero-Day Vulnerabilities Rapidly

The breach at the Dutch Institute for Vulnerability Disclosure shows how quickly a serious security incident can unfold when an AI-enabled operator can chain flaws without pausing for human direction. The immediate lesson is uncomfortable: many defense programs are still organized around attacker timelines that may no longer exist.

DIVD, a nonprofit that reports vulnerabilities and serves as a CVE Numbering Authority, said attackers entered its systems on September 21 through two previously unknown flaws in its Zammad helpdesk platform. The reported chain moved from session hijacking to code execution as the Zammad application user and then to root-level access within seconds. DIVD discovered the activity the next day, restricted access to its data-center systems, and brought in Merlon Security for incident response.

The organization said data connected to volunteer security researchers was taken, including DIVD email addresses and potentially other contact details. The exact scope remains under investigation. That exposure creates a direct risk of impersonation: a message that appears to come from a known researcher or from DIVD can carry far more weight than a generic phishing email.

DIVD also said evidence in logs and attack scripts pointed to an agentic AI-powered operation. That attribution should be read carefully. Public evidence can show automated decision-making, unusual speed, and distinctive artifacts, yet it may not identify the people who set the task, supplied the tools, or chose the target. Even with that limitation, the incident deserves urgent attention. The operational pattern described by DIVD is precisely the pattern security teams must plan for: rapid, adaptive exploitation of a vulnerability chain with enough autonomy to make the next move before an analyst has opened an alert.

The two disclosed Zammad issues received CVE identifiers CVE-2026-102489 and CVE-2026-102490. DIVD assessed the chained attack scenario at CVSS 4.0 severity 9.4. The first issue can allow an unauthenticated attacker to leak user sessions and obtain remote code execution as the local Zammad user. The second lets a local user elevate privileges to root.

That sequence matters because support platforms usually sit in a trusted part of an organization. They collect customer messages, support attachments, internal notes, user records, and password-reset related communications. They are frequently internet-facing and often connect to email systems, identity services, or other operational tooling. A compromise there can provide both technical access and a rich source of material for later social engineering.

According to DIVD’s advisory, Zammad versions 6.3.0 through 6.5.4 are vulnerable to CVE-2026-102489. The issue also exists in versions 7.0.0 through 7.1.3, although DIVD said environmental conditions prevent exploitation in those releases. CVE-2026-102490 affects all Zammad versions. DIVD advised users to upgrade to version 7 or take their Zammad instances offline. Organizations should follow vendor and DIVD updates closely, since the details of patches, mitigations, and exploitability can change quickly during an active response.

The key security failure is not exotic when viewed one stage at a time. One flaw gives a foothold, another turns that foothold into full server control. Chaining is what produces the severe outcome. Security teams regularly rank findings individually, assign an owner, and schedule remediation according to a ticketing queue. That process can miss the way several medium-to-high impact conditions combine on a real host. External exposure, an exploitable session weakness, an application-level execution path, and excessive local privileges can form a direct route to a major breach.

The DIVD breach illustrates how an AI-enabled operator reportedly chained two Zammad zero-day vulnerabilities to move from session compromise to code execution and root access within seconds. The incident shows why defenders must assess complete attack paths rather than isolated vulnerabilities, combine application and host telemetry, prepare machine-speed containment, and treat stolen contact information as a continuing social-engineering risk.

DIVD described the intrusion as loud, messy, and automated. It said the attacker appeared to choose subsequent actions after each prior action at extraordinary speed. Investigators also found comments in attack scripts that appeared to explain or justify actions. The organization viewed those traces as signs of an agent carrying out a task rather than a human operator typing through an established playbook.

Those indicators are valuable, though they are not proof of a fully autonomous system operating without a human. Attackers can automate scripts, leave misleading artifacts, or use AI only for a limited portion of an operation. The important defensive fact remains the same: the activity behaved at a pace and with an adaptive sequence that can overwhelm controls designed for a person working a keyboard.

Agentic systems can break a target objective into smaller tasks, inspect outputs, choose tools, retry failed actions, and pivot when a route is blocked. A human can set the objective and then supervise only exceptions. That arrangement reduces the labor required for reconnaissance and exploitation, while allowing attacks to continue across time zones and outside normal working hours.

The same traits introduce weaknesses. An agent can make incorrect assumptions, generate needless traffic, follow a poor path repeatedly, and produce an unusually detailed forensic trail. DIVD’s ability to observe noisy actions and comments may have helped its investigation. Defenders should not treat this sloppiness as a reliable safeguard. A noisy automated attack can still reach root access in seconds, take data, and establish persistence before response personnel recognize what is happening.

The incident therefore marks a change in the practical economics of intrusion. Chaining vulnerabilities once demanded a skilled operator’s close attention. AI-assisted workflows can give more actors the capacity to test paths, handle routine decisions, and execute actions far faster than a manual operation. The underlying flaws still need to exist, and reliable exploitation still takes capability. Yet the time available to detect and interrupt the chain has shrunk sharply.

A security operations center cannot expect an analyst to manually evaluate every suspicious event before an automated attacker proceeds. The useful goal is to contain high-confidence attack behavior rapidly while retaining enough evidence for investigation. That means defining which combinations of activity trigger immediate protective actions.

For an internet-facing helpdesk, examples include a sudden session anomaly followed by application process execution, an unexpected child process spawned by the service account, a privilege escalation attempt, or outbound connections from a server that normally has limited network duties. Any one signal can be ambiguous. A compressed sequence of them on the same host should produce an urgent response.

Organizations running Zammad or comparable platforms should verify that application, operating system, identity, endpoint, and network telemetry reaches a central system with accurate timestamps. Logs held only on the compromised server may disappear with the host. Retention also matters. A response team needs pre-incident activity to establish whether access began before the detected intrusion and whether the attacker returned through another route.

Endpoint detection tools should monitor service accounts and application processes for shell launches, unusual interpreters, permission changes, privilege escalation behavior, new scheduled tasks, and outbound traffic that conflicts with the host’s expected role. Detection engineering should account for application-specific normal behavior. A rule that fires constantly becomes ignored, while a rule tied to a meaningful sequence gives responders a usable signal.

Containment decisions need preparation as well. Teams should know who can remove a server from the network, suspend a suspicious session, disable a service account, rotate credentials, and invoke a continuity plan for the customer-support function. DIVD restricted access to its data-center systems after identifying the breach. That kind of decisive action is easier when business leaders have agreed beforehand that a temporary service disruption is justified by evidence of active compromise.

The most important lesson is not whether the attacker was completely autonomous; it is that defenders can no longer base response plans on a human-paced intrusion. When an exposed application combines a usable foothold with excessive local privileges, automation can turn ordinary control weaknesses into a full compromise before a conventional ticket queue or analyst workflow reacts. Security programs should therefore measure how quickly they can identify, isolate, and investigate a chained attack—not merely how quickly they can close individual findings.

A monthly patch cycle remains useful for routine vulnerabilities, but it is not enough for a publicly reported, actively exploited zero-day chain on an exposed system. Security and infrastructure teams need an emergency path that can inventory affected systems, assess internet exposure, apply a safe update or compensating control, and validate the result within hours.

Asset inventories are central here. Many organizations know they operate a ticketing function but cannot quickly identify every deployed version, reverse proxy, container image, test environment, or unmanaged instance. That uncertainty gives attackers room. A complete inventory should tie the application to an owner, a business dependency, a support lifecycle, authentication method, and reachable network paths.

The local privilege escalation issue also highlights a familiar problem: application accounts commonly have more power than they need. The Zammad service account should have only the permissions required for normal operation. Hardening the host, limiting sudo rules, separating workloads, using mandatory access controls where practical, and restricting access to sensitive secrets can reduce the damage from an application-level compromise. These measures may not eliminate a specific vulnerability, but they can stop a single flaw from becoming total host control.

Network segmentation provides another useful brake. A helpdesk server rarely needs broad access to internal administration systems, development environments, or data stores. Allowlisting necessary connections and blocking the rest limits pivot opportunities after the initial breach. Egress filtering deserves similar attention. An attacker with root access can still face obstacles when the server cannot freely send data or open arbitrary command-and-control channels.

DIVD’s warning about volunteer email addresses and other contact details should be taken seriously. Breach victims often focus on passwords, tokens, and proprietary records while treating contact information as low sensitivity. In a security research organization, names, roles, affiliations, email addresses, and a believable work context can help an attacker construct highly targeted fraud.

A message could reference a current disclosure, a supposed vulnerability report, an urgent request to review an attachment, or a change in incident communications. It might imitate a known DIVD volunteer, reporter, vendor contact, or researcher. The technical breach can thus create a much longer campaign directed at individuals who already work in high-trust technical networks.

DIVD advised people who receive a contact request or email that feels unusual to verify it by writing to communications@divd.nl. Organizations in a similar position should publish a clear verification channel, tell affected people what information was exposed, and explain which communications they will never request. Staff and volunteers need a simple procedure for reporting suspicious messages without embarrassment or delay.

Credential resets and stronger authentication are appropriate when a breach may have exposed session data or account-related information. Phishing-resistant multifactor authentication, such as passkeys or hardware-backed security keys, can reduce the usefulness of stolen passwords. It does not solve every impersonation risk, so verification of unusual requests remains necessary even for people protected by strong login controls.

DIVD disclosed the incident while its investigation was still under way, reported the Zammad flaws to the vendor, notified the Dutch Data Protection Authority and the National Cyber Security Centre, and discussed options with police. That is difficult work for any organization, especially one whose mission involves finding other people’s security problems. It is also the responsible path.

Early disclosure gives administrators a chance to find affected software, raise monitoring, and make containment decisions before a similar attack reaches them. It lets researchers examine indicators and technical behavior. It gives potentially affected people an honest basis for handling suspicious contacts. Silence may preserve appearances briefly, but it leaves peers exposed to a threat that has already been demonstrated in the wild.

There is a practical lesson for boards and senior leaders here. A mature incident response program should include pre-approved communications processes, technical disclosure ownership, legal and regulatory contacts, and criteria for notifying affected people. Teams that have to negotiate every public statement during an unfolding incident lose time and create avoidable confusion.

The DIVD breach should push organizations toward a harder assessment of their exposed applications and incident readiness. AI-enabled attackers do not remove the need for ordinary security basics. They make failures in those basics more expensive because the attacker can discover and exploit a chain in a much shorter window.

The immediate priorities are clear: identify all Zammad deployments and their versions; apply verified vendor and DIVD guidance or isolate affected systems; review logs and endpoint telemetry for suspicious sessions, process execution, and privilege escalation; rotate credentials and secrets that may have been reachable; and prepare people for tailored impersonation attempts. Similar review should extend to other internet-facing applications that hold sensitive communications or run with elevated local permissions.

The longer-term task is to build defenses around attack paths rather than isolated alerts. Security teams need richer telemetry, rapid containment authority, hardened service accounts, segmented environments, and exercises that assume an intruder can make several decisions in seconds. Human analysts remain essential for judgment, scope assessment, and recovery. Their tools and operating procedures must give them a realistic chance to interrupt automated intrusion before it spreads.

DIVD’s experience is a warning from an organization that understands vulnerabilities well and chose to disclose its own failure plainly. The attack did not require a futuristic breakthrough. It combined two serious weaknesses with a form of automation that is already accessible to capable threat actors. Treating that combination as an urgent design condition, rather than a distant possibility, is now part of responsible security practice.