On this pageIntroduction
Introduction
Strand Intelligence have been investigating the recently disclosed Zammad vulnerabilities exploited in the wild, notably against the Dutch Institute for Vulnerability Disclosure (DIVD). This incident demonstrates the use of AI agents for post-exploitation activity, and its downstream impact on organisations and businesses.
The Evolving Vulnerability Research Landscape
Traditional vulnerability research involves hours of trawling through code, decompiling binaries, tracing program flows, and analysing memory allocations or logical decisions within the target program.
It was an arduous process, but those with the knowledge and perseverance could be highly rewarded with an exploitable 0-day vulnerability. A "0-day" is a vulnerability for which a patch is not yet available when it is exploited, leaving organisations without a patch they can apply to protect themselves. That is what makes 0-days so powerful. Without public IoCs or signatures, detecting exploitation can be harder, and incident response teams often see a huge spike in volume when a large 0-day vulnerability appears as multiple businesses vulnerable to the issue are targeted at once.
Researchers therefore tend to guard 0-days closely, especially those operating in a grey- or black-hat capacity. White-hat researchers conventionally follow responsible disclosure, through bodies such as ZDI and MITRE or directly to the vendor.
Following public disclosure, a vulnerability is often referred to as an "n-day", reflecting how long it has been publicly known. N-days are considered less valuable: newer product releases may have patched them, IoCs can be integrated into EDR products, and forensic analysts can look for known artefacts of exploitation.
0-days are therefore generally considered “high-equity”: their lower detection profile makes them extremely valuable to operators seeking to conceal malicious activity.
Elevated Powers for Threat Actors
Financially motivated threat actors have long relied heavily on “low-equity” n-days: a constantly rotating pool of newly disclosed vulnerabilities and associated exploit scripts, with plenty of unpatched product instances typically remaining online after disclosure.
The RondoDox botnet is a well-rounded embodiment of this approach. Below is a graphic to visualise this at a high-level.
This was usually quite a noisy approach, yet provided a good-enough success rate to generate profit for the group. In their eyes, as long as they ensure their infrastructure is covert and avoids any attribution back to their real-world identities, this is a profitable and sustainable business model.
Agentic tooling for SRE and vulnerability research is now becoming both far more mature, and more widely commercially available - with Anthropic's Mythos being a keystone of any recent conversation on this topic.
Pwn2Own Berlin in May 2026 was over-subscribed, with more registrations than the organisers could accommodate. The newly added AI categories targeted vulnerabilities in AI products, rather than requiring researchers to use AI to find them.
Now, with the rise of agentic research tooling, the operating model for threat actors is shifting as the barrier-to-entry for finding 0-days may become lower. The low detection profile provided by exploiting a 0-day rather than an n-day can give the operator more time to map out networks of internal business systems and to exfiltrate more sensitive data.
What Happened with Zammad and DIVD
Zammad is an open-source, AI powered support platform encompassing a ticket management system and a knowledge base. Zammad can be deployed as a self-hosted instance or through the service hosted and maintained by Zammad GmbH. With the source code being openly available on Zammad's GitHub repo it is open to the scrutiny of any researcher with internet access.
Open-source development generally favours the blue team: a large pool of developers maintains the codebase and continually monitors for insecure coding patterns. Yet, as Zammad shows, red-team operators can still piece together a path to Remote Code Execution (RCE) and system compromise.
On the 21st September 2026 attackers chained two 0-day vulnerabilities in the Zammad platform to gain access into the Dutch Institute for Vulnerability Disclosure (DIVD). From there, they were able to access and partially exfiltrate sensitive data from a privileged position in the network.
The two vulnerabilities have since been assigned CVE numbers:
CVE-2026-102489 used for initial access
CVE-2026-102490 used to gain elevated privileges
Fortunately, DIVD was able to swiftly identify the malicious activity, although response and containment took longer. A timeline taken from their report is below:
DIVD reported detection in 19 minutes, a first response after 19 hours, and a further 9 hours to contain the attack.
What's notable in the report is the attribution of post-exploit activities to AI agents. DIVD have performed this attribution on the following behaviour observed in their forensic investigation:
The sheer volume of the attack and the number of artefacts generated, in a relatively short period.
The fact that attack scripts are commented and documented, and that the attack agents seem to be talking to each other in the comments of the scripts
The OpSec Behind the Investigation
The volume of network enumeration and data collection described by DIVD runs against conventional 0-day exploitation operational practice, especially when the subject of the attack is a cybersecurity and vulnerability disclosure organisation.
A 0-day can lose significant value once exploitation is detected - investigators will utilise all the evidence and tooling at their disposal in order to conduct Root Cause Analysis (RCA), establishing exactly how attackers accessed the systems. Vulnerability disclosure may follow a successful investigation, and the 0-day can be effectively "relegated" to an n-day.
For this reason, operators abusing a 0-day usually take great care to maintain a low profile inside the target environment, minimising logs and forensic artefacts that they generate with their malicious activity. They aim to preserve the exploit for as long as possible and reserve it for the highest-value targets.
Generating large volumes of post-exploitation activity sits at the opposite end of the OpSec spectrum, undermining the “hard to find, harder to detect” advantage of 0-days.
An agentic process is inherently an iterative one. LLMs can prioritise exploration, execution velocity, and task completion over state-management or co-ordination. This can lead to over-enumeration and a colossal volume of activity on both the network interfaces and filesystem of the subject. Granting the AI freedom and autonomy without enforcing approval policies can amplify this effect.
The diagram below illustrates this loop:
With the appropriate guardrails in place, an actor may be able to successfully evade detection while utilising agentic exploitation. However, that does not seem to have been the case in the DIVD incident.
Examining the Initial Access Vulnerability
The initial-access exploit itself chains several “primitives” to achieve fully unauthenticated RCE. A primitive is code functionality that enables a basic operation, such as reading arbitrary information or writing data to a file, which can be combined with other primitives to form an exploit.
This attack (CVE-2026-102489) chains the following primitives together to achieve RCE as a fully unauthenticated user: information leak → session hijacking → code execution through an authenticated package upload. This shows how several small development mistakes can create a devastating security vulnerability.
The diagram below shows the traffic flow of the attack:
It's important to note here that there is no indication whether AI was involved in the discovery of the vulnerabilities in this case, although it is entirely possible. With readable Ruby source available in the open-source repository, this is precisely the kind of task agentic research tools handle exceptionally well.
We will break the vulnerability down into its three primitives for analysis. We have also conducted sandbox testing of this exploit against a Zammad instance in our lab environment to demonstrate how the Strand platform identifies intrusions akin to this one.
Part 1: Information Leak
Session hijacking lets attackers bypass authentication by impersonating an already logged-in user. Here, an overly verbose error message enables it by leaking details of active server-side sessions.
An unauthenticated attacker can force this error to occur by sending specific data to the server through the WebSockets interface. WebSockets is an application layer protocol - it is designed to work over HTTP ports 443 and 80 as well as to support HTTP proxies and intermediaries.
The attacker sends a simple WebSockets message containing the following JSON:
{"event": "base"}Sending {"event":"base"} triggers an error because the Sessions::Event::Base class doesn't implement the instance method run(), which Zammad's WebSocket event dispatcher expects to call, causing Ruby to raise a NoMethodError exception. A reconstructed example of the exception message is contained below, showing that it leaks connection details in the @clients field where it dumps the headers from the HTTP request, including the cookie.
[
{
"event": "error",
"data": {
"error": "undefined method `run' for #<Sessions::Event::Base:0x00007df4528c1378 ...>",
"exception": {
"type": "NoMethodError",
"message": "undefined method `run' for Sessions::Event::Base",
"object": {
-- clipped --
"clients": {
"199640": {
"headers": {
-- clipped --
"Cookie": "_zammad_session_a138cfd0f37=5b72e71f6482c72bdfa903399e98aa7c"
},
"session": {
"id": 3
}
}
},
-- clipped --
"is_web_socket": true
}
},
"payload": {"event": "base"}
}
}
]Part 2: Session Hijacking
A request to /api/v1/users/me confirms that the stolen session cookie authenticates the attacker as the user. It also returns details of the user account including the name and the roles/privilege level - an admin account is required to upload custom Zammad packages in the next step, and the name value is used later when triggering a password reset.
With the harvested session details, the attacker can now make requests to authenticated endpoints, allowing them to carry out actions that only logged-in users should be able to do.
Prior to uploading the malicious ERB template, the attacker must obtain the CSRF token granted to this session, which is easily done by reading it from the HTTP response headers. In this example, a new request to the webroot retrieves it.
Part 3: ERB Template Upload and Execution
Zammad uses its own package format, .zpm (Zammad Package Module).
A .zpm package contains JSON metadata and a list of files to install. Each file entry includes a location specifying where the package manager should write it, relative to the application's root directory. The app/views directory is intended for custom application views and templates.
Our PoC uploads the malicious ERB template to app/views/mailer/password_reset/en.html.erb.custom. The .erb.custom suffix is significant because the file is intended to supply a custom version of Zammad's password-reset email template.
Malicious executable Ruby expressions are embedded inside the template. Triggering a password reset through a POST request to /api/v1/users/password_reset subsequently causes the template to be rendered, executing the embedded Ruby code.
In our PoC, the embedded Ruby code uses sub-command syntax (backticks) to execute a system command, then writes the command output to a file with File.write().
<%= ::File.write('{out_file}', `{payload}`) %>We used a payload which creates a new admin account on the target Zammad instance.
cd /opt/zammad && /docker-entrypoint.sh bundle exec rails runner 'user = User.create!(firstname: "Joe", lastname: "Bloggs", login: "test@example.com", email: "test@example.com", password: "J0esPassword", active: true, roles: Role.where(name: ["Admin", "Agent"]), created_by_id: 1, updated_by_id: 1);'Evidence of the account being created is visible in the "Activity Stream" on the right-hand side of the dashboard, shown in the next section.
Post-exploitation
With the attacker-controlled Admin account now created on the system, the threat actor is free to log into the system just as a regular user would, and begin exploring the portal:
From here, masquerading as a threat actor and using a VPN for the connection, I changed the session timeout value to 0 in the system settings to further consolidate my access.
In a real-world compromise, the threat actor would now begin to enumerate any sensitive data on the platform, looking for customer data as well as opportunities to move laterally into other systems belonging to this company or gain elevated privileges.
Fingerprinting Live Zammad Servers
CVE-2026-102489 applies to Zammad servers from version 6.3.0 to 6.5.4. The vulnerability is also present in version 7.0.0 to version 7.1.3; however it is not exploitable in these versions due to environment constraints.
We have run a Censys query to ascertain a count of live Zammad servers on the internet. The query was run on the 9th October 2026 and returned a count of 1,890 results.
The fingerprint used to identify Zammad servers:
host.services.endpoints: (
http.body: "zammad_form_script"
and http.headers: (
key = "Set-Cookie"
and value: "_zammad_session_"
)
)This fingerprint was developed against our testing server running version 6.5.2, but is verified to apply up until the current alpha version 7.3.0-alpha. No testing has been done for versions prior to 6.0 since the previous version, 5.4.1, became end of life in 2023 when version 6.0 was released.
Responding to a Suspected Compromise
Zammad recommends upgrading self-hosted instances to version 7.2.2. An emergency release, 6.5.5, was published on 15 October 2026 to address CVE-2026-102489 for users who cannot yet upgrade. It requires a new package repository and does not extend support for the 6.5 branch. Zammad SaaS customers do not need to take action.
If compromise is suspected, preserve the application and reverse-proxy logs, Docker volumes and host forensic artefacts before rebuilding. Review account creation, changes to session settings, package uploads and removals. DIVD's case page includes a log-checking script for known indicators of compromise.
Strand Intelligence Detection of Malicious Activity
UAC was used with a custom profile to do a forensic capture of evidence from our compromised Zammad server. This contained the artefacts from UAC's full profile as well as Docker volumes, log sources, and other artefacts relating to this deployment of Zammad.
After creating an incident on the Strand platform, submitting the UAC evidence archive, and running the agentic attack path analysis (note Strand had zero existing knowledge of the vulnerability for this test – we did not allow it to research the vulnerability beforehand or rely on external information) we can see that Strand has successfully identified the exact flow of the exploitation from first principles - beginning with initial reconnaissance and initial access, through to persistence and attacker clean-up in the impact section. The attack path shows what happened extremely clearly, stating attacker IP addresses, timestamps, and references to the raw forensic evidence.
The findings linked the initial WebSocket activity to package installation, creation of a new admin account, and changes to session timeout settings. Strand also identified the later package removal as clean-up, even though the malicious template itself had been deleted.
Much has been said about the use of AI in cybersecurity – and rightly so. There are dangers and tradeoffs to consider when relying on AI to detect threats and respond to incidents, just as there are for attackers using AI to conduct their attacks, but zero-day vulnerabilities such as this one highlight some true benefits. Without relying on known vulnerability information, IOCs, or signatures in the way a traditional monitoring platform could – and instead recreating the steps an experienced forensic analyst would perform against raw, underlying operating system and traffic logs – Strand could successfully identify and recreate the attack path, provide a detailed analysis of how the attack took place, and save countless hours for companies and responders looking to identify how a threat actor gained access, even when they used a previously unknown, undisclosed vulnerability.
To see Strand in action, fill out our contact form today at strandintelligence.com/contact.
Glossary
SRE - Software/Systems Reverse Engineering
IoC - Indicator of Compromise
VR - Vulnerability Research
ZDI - Zero Day Initiative
EDR - Endpoint Detection and Response
RCE - Remote Code Execution
PoC - Proof of Concept
CSRF - Cross-Site Request Forgery (CSRF tokens prevent this)
OpSec - Operational Security
CVE - Common Vulnerabilities and Exposures (public dictionary of known system and software vulnerabilities)
UAC - Unix-like Artifacts Collector
