> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# Zammad Zero-Days Exploited in AI-Powered DIVD Hack
- URL: https://f4n6.co.uk/security-feed/zammad-zero-days-exploited-in-ai-powered-divd-hack/
- Published: 2026-10-01T12:24:40.000Z
- Updated: 2026-10-01T12:24:40.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

The Dutch Institute for Vulnerability Disclosure (DIVD) was breached on 21 September 2026 by an attack that chained two zero-days in Zammad, the open source web ticketing and user support platform, to hijack sessions, run code remotely, and escalate from a Zammad user to root. DIVD attributes the modus operandi to an agentic AI-powered attack, a claim that is single-sourced to DIVD and not corroborated by a second party. The two flaws are CVE-2026-102489 (unauthenticated remote code execution and session leakage) and CVE-2026-102490 (local privilege escalation to root), both reported at CVSS 9.4 by DIVD; no verified reference data resolved for this item, so those scores are the source's own and have not been independently re-scored. Zammad versions 6.3.0 through 6.5.4 are exploitable; 7.0.0 through 7.1.3 carry the defect but DIVD states exploitation is not possible there due to environment conditions. Any EMEA financial services firm running Zammad 6.x as an internal or customer-facing ticketing system should treat this as an active-exploitation event against an internet-reachable application, with the added risk that the same platform often holds correspondence, attachments, and identity data.

## 2\. Regulatory framing

| Article                                                                         | Trigger (the fact in this item)                                                                                                                                                                                      | Practical impact                                                                                                                                                                                                         |
| ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| DORA Art. 17: ICT-related incident management process                           | A self-hosted or third-party-hosted Zammad instance is an ICT system in the firm's operational estate; the exploited flaws give unauthenticated RCE and root, which is a live incident if the instance is reachable. | The firm's incident management process must be able to detect, contain and recover a compromise of the ticketing platform itself, including the case where the platform is the entry point to adjacent services.         |
| DORA Art. 19: reporting of major ICT-related incidents to competent authorities | DIVD reports the attackers pivoted from the Zammad instance to other services and exfiltrated data, and states it assumes breach.                                                                                    | If a client's own Zammad instance is hit and the incident meets the major-incident classification, the reporting clock to the competent authority starts from detection, not from the end of the investigation.          |
| NIS2 Art. 23: incident reporting obligations                                    | Same trigger: confirmed exploitation of an internet-facing application leading to data exfiltration and lateral movement.                                                                                            | In-scope entities must file the early warning and incident notification within the timelines set by the article; the DIVD case is the worked example of why the initial notification cannot wait for root-cause closure. |

No DORA Art. 24, 28, 29 or 30 mapping is asserted here: the source does not identify a third-party ICT provider relationship or a concentration issue, and the testing obligation is not triggered by a specific fact in this item.

## 3\. Technical analysis & attack chain

Confirmed steps, as reported by DIVD:

1. The attacker reached the Zammad instance and exploited CVE-2026-102489, which requires no authentication, to leak user sessions and achieve remote code execution.
2. With code running as the Zammad user, the attacker exploited CVE-2026-102490 to escalate privileges to root.
3. DIVD states the session hijack, remote code execution and escalation to root completed in seconds, which it attributes to the agentic part of the attack.
4. From the Zammad instance the attacker pivoted to other services and exfiltrated data.
5. Network segmentation stopped the attacker from going deeper into the environment.

CVE-2026-102489 is the initial access vector: unauthenticated, network-reachable, and it does two things at once, leaking user sessions and giving remote code execution. The session leak matters independently of the RCE, because a stolen Zammad session is a valid authenticated session and does not require the RCE to be re-run. CVE-2026-102490 is the post-exploitation step: a local user, which the first flaw provides, elevates to root. DIVD's own framing is that the two are used together, so treating either in isolation understates the exposure.

Affected versions, per DIVD: 6.3.0 to 6.5.4 are affected and exploitable. Versions 7.0.0 to 7.1.3 contain the security defect but exploitation is not possible due to environment conditions. DIVD's advisory tells all Zammad users to upgrade to version 7 or take the instance offline. Zammad has been working on a fix; the source does not name a fixed version, a patch release date, or a vendor advisory identifier, and no CVE record or vendor bulletin was available to Adverse Trace at the time of writing.

The German federal CERT (BSI) rates the Zammad vulnerabilities as kritisch and describes the impact as an anonymous remote attacker executing arbitrary code with user rights and obtaining root. BSI does not name the CVE identifiers in the material available to us, so the mapping between the BSI advisory and CVE-2026-102489 / CVE-2026-102490 is inferred from product and impact, not stated by BSI.

Unconfirmed and single-sourced claims, flagged as such:

- The agentic AI characterisation rests entirely on DIVD's own 24 September LinkedIn post and its 30 September statement. No second party has corroborated that an AI agent drove the exploitation. Treat "AI-powered" as DIVD's assessment of the modus operandi, not as an established fact about the tooling.
- The scope of data exfiltration is not quantified. DIVD says data was exfiltrated and that it assumes breach, but names no data category, volume, or affected party.
- The pivot targets are not named. DIVD says the attackers moved from Zammad to other services; it does not identify them.
- No atomic indicators, file names, command lines, or C2 addresses appear in the source material. DIVD states it published a verification script to hunt for IoCs, but the script contents are not in our sources.

## 4\. Mitigation & containment

P1, within 24 hours:

- Inventory every Zammad instance in the estate, including departmental and shadow deployments, and record its exact version. The exploitable band is 6.3.0 to 6.5.4.
- For any instance in 6.3.0 to 6.5.4 that is internet-reachable, either take it offline or place it behind authentication and network restrictions until it is upgraded. DIVD's own guidance is to upgrade to version 7 or take it offline.
- Treat any instance in the exploitable band as potentially compromised. Rotate Zammad user sessions and API tokens, and rotate credentials for any service the Zammad host could reach, because CVE-2026-102489 leaks sessions and CVE-2026-102490 yields root on the host.
- Hunt for the pivot. DIVD's attackers moved from Zammad to other services, so review authentication logs on services that trust the Zammad host or share credentials with it, and check for outbound connections from the Zammad host to internal services it has no business reaching.
- Run DIVD's published verification script against Zammad instances to check for compromise. The script is referenced in DIVD's advisory; obtain it from DIVD directly rather than from a third party.

P2, within 72 hours:

- Upgrade all Zammad instances to version 7\. Versions 7.0.0 to 7.1.3 still contain the defect but are not exploitable per DIVD's environment-conditions assessment, so version 7 is the interim safe position and not a permanent fix. Track Zammad for the actual patched release; the source does not name one.
- Confirm network segmentation between the Zammad host and the rest of the environment. DIVD states segmentation is what stopped the intrusion from going deeper, which makes it the control that has already been proven to work in this case.
- Review Zammad's own logs for session anomalies: sessions created or used from unexpected source addresses, sessions surviving a password or token change, and administrative actions taken outside normal hours.

P3, within 7 days:

- Add Zammad to the external attack surface inventory with an owner and a review cadence, so the next Zammad advisory does not require a manual sweep.
- Where Zammad is customer-facing, review whether ticket content, attachments, or embedded identity data would make a compromise reportable under the client's own regulatory obligations, and pre-draft the notification so the clock is not lost to drafting.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. The sources name no hashes, domains, IP addresses, file paths, registry keys, or command lines. DIVD states it published a verification script for hunting IoCs, but its contents are not in our sources and we will not reproduce or guess at them.

Behavioural indicators, from DIVD's account of the intrusion:

| Behaviour                                                                            | Where to observe                                                   | Confidence                                          |
| ------------------------------------------------------------------------------------ | ------------------------------------------------------------------ | --------------------------------------------------- |
| Session hijack on Zammad followed by authenticated actions from an unexpected source | Zammad session and audit logs, reverse proxy access logs           | High, DIVD states session hijack occurred           |
| Remote code execution as the Zammad service user                                     | Host process telemetry on the Zammad server, EDR process tree      | High, DIVD states RCE occurred                      |
| Privilege escalation from the Zammad user to root                                    | Host audit logs, sudo/auth logs, EDR privilege events              | High, DIVD states escalation to root occurred       |
| Pivot from the Zammad host to other internal services                                | Firewall and netflow between the Zammad host and internal segments | High, DIVD states the pivot occurred                |
| Data exfiltration from the Zammad host or pivoted services                           | Egress monitoring, proxy logs, DLP                                 | High that exfiltration occurred, scope unquantified |
| Rapid completion of the full chain, seconds from session hijack to root              | Correlated timeline across Zammad logs and host telemetry          | Medium, DIVD's timing claim is single-sourced       |

## 6\. Detection

The sources contain no file artefacts, command lines, mutexes, or hard-coded values from the threat itself, so a YARA rule built from this material would only match reporting about the incident, not the incident. No YARA rule is emitted.

A Sigma rule is possible for the behavioural pattern DIVD describes: a Zammad service process spawning a shell or escalating to root. The rule below keys on the Zammad process context and the escalation, both of which are stated in the source. Adjust the parent process name to match the client's deployment.

```yaml
title: Zammad Service Process Spawning Shell or Escalating to Root
id: 8f2c1a44-7d3e-4b21-9c6a-0e5b7a1d9f30
status: experimental
description: Detects a Zammad service process spawning a command shell or a privilege escalation to root, consistent with the CVE-2026-102489 and CVE-2026-102490 chain reported by DIVD.
author: Adverse Trace
date: 2026-10-01
references:

  - https://www.securityweek.com/zammad-zero-days-exploited-in-ai-powered-divd-hack/
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:

      - '/zammad'
      - '/ruby'
  selection_child:
    Image|endswith:

      - '/sh'
      - '/bash'
      - '/sudo'
      - '/su'
  condition: selection_parent and selection_child
falsepositives:

  - Legitimate Zammad maintenance scripts or administrative tasks run from the service account
level: high
tags:

  - attack.execution
  - attack.privilege_escalation

```

The rule is deliberately narrow. It will miss an attacker who escalates without spawning a shell, and it will fire on legitimate maintenance. Tune the parent image list to the client's Zammad deployment before enabling it at high severity.

## 7\. Sources

- SecurityWeek, "Zammad Zero-Days Exploited in AI-Powered DIVD Hack", https://www.securityweek.com/zammad-zero-days-exploited-in-ai-powered-divd-hack/, 2026-10-01
- BSI Germany, "\[NEU\] \[kritisch\] Zammad: Mehrere Schwachstellen ermöglichen Ausführen von beliebigem Programmcode und Privilegieneskalation", https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-3694, date not stated in source

The DIVD advisory, the DIVD verification script, and the DIVD LinkedIn post of 24 September 2026 are referenced by SecurityWeek but were not available to Adverse Trace at the time of writing. Clients should obtain the verification script from DIVD directly.

## 8\. Adverse Trace position

We assess this as a high-severity, actively exploited event against a widely deployed open source ticketing platform, with the caveat that the two CVSS 9.4 scores are DIVD's own and no verified reference data resolved for this item, so we have not independently re-scored them. The exploitation is confirmed by DIVD against its own infrastructure; the agentic AI characterisation is single-sourced to DIVD and we treat it as unconfirmed. The practical exposure for EMEA financial services clients is a Zammad 6.x instance that is internet-reachable and holds correspondence, attachments, or identity data, and the pivot and exfiltration DIVD describes is the outcome we would expect in an environment without segmentation. We will track Zammad for the patched release and for a vendor advisory naming the fixed version, and we will update this note when DIVD's verification script or a second-party account of the intrusion becomes available. Clients running Zammad 6.3.0 to 6.5.4 should confirm to us within 24 hours whether the instance is internet-reachable and whether it has been upgraded or taken offline.

---

[Read the original source →](https://www.securityweek.com/zammad-zero-days-exploited-in-ai-powered-divd-hack/?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*