Hunt Zammad CVE-2026-102489/102490: session to root

The Dutch Institute for Vulnerability Disclosure finds exposed systems for a living. On 21 September 2026 someone got into its own. DIVD noticed the next day and blocked access to its datacenter systems. The attacker's scripts contained notes where the agent justifies its own actions, explaining why what it is doing is okay and really not phishing. DIVD says a human attacker wouldn't bother, and it describes the intrusion as an agentic AI powered attack. That description is DIVD's.

The way in was two Zammad flaws. CVE-2026-102489 is a session fixation bug that DIVD says leads to remote code execution as the zammad user. CVE-2026-102490 lets that local user become root. DIVD says the move from hijacked session to root took seconds. CISA added both to the KEV catalog on 2 October 2026, with a due date of 2026-10-05 and forensic triage required.

Carry two questions. Do you run Zammad, on which version, and can the internet reach it? And if the zammad account became root tonight, would any log leave the box to tell you?

How the attack works

Step one: a session that belongs to someone else

DIVD describes CVE-2026-102489 as a session hijack leading to code execution as the zammad user. SecurityWeek says unauthenticated attackers can reach it.

DIVD lists Zammad 6.3.0 to 6.5.4 as exploitable. The flaw is also present in 7.0.0 to 7.1.3, but DIVD says it is not exploitable there because of environment conditions. Zammad says exploitation is only possible on 6.5 and older. Sysdig notes impact before 6.3.0 is unknown. No triggering request is published, and we will not guess at one.

Step two: from the service account to root

DIVD says CVE-2026-102490 affects every Zammad version from 1.5.0 up to and including the latest alpha, and lets the local zammad user escalate to root. Zammad says an attacker would already need access to the server.

Sysdig points out that a host that blocks the first flaw is still exposed to this one by attackers who find local code execution another way.

What the agent did next

Sysdig reports that with root the agent ran password spraying and a man-in-the-middle attack, with targets unclear. DIVD called the operation loud and messy. Sysdig adds that a better-built agent may make less noise, but the behaviors would not change, so the hunts below follow behavior.

Risk: what the helpdesk holds

Sysdig says a helpdesk host concentrates secrets: database credentials, mail and API tokens, and API keys for every system the support team touches. Root exposes all of them at once.

DIVD is the only named victim. It says volunteer data got out, such as email addresses and possibly contact details. Sysdig's summary adds signs of compromise in the CSIRT ticketing system, which holds every email sent to the CSIRT mailbox and every reply, though DIVD believes it was only partially extracted. DIVD says segmentation stopped the attackers from going deeper.

DIVD sees no link to any known public threat actor, and CISA lists ransomware campaign use as Unknown. We cite no other victims or counts.

Our reading: a ticket system also holds your customers' messages.

Mitigate and reduce risk

Patch status today, and why to recheck it

As of 4 October 2026, this is what each source says. Recheck before acting.

• DIVD case DIVD-2026-00015 (last modified 1 October 2026) shows Patch status as Available, with the recommendation "Upgrade to Zammad version 7" and Workaround as N/A. The same page says Zammad is "working on a fix". Our reading: the Available label sits beside an LPE range that includes the latest alpha, so do not read it as a root-escalation fix.

• Zammad says CVE-2026-102489 does not affect 7.0 and later, and that it hardened the code anyway in 7.2.0. For CVE-2026-102490 it said on 1 October 2026 that it had received DIVD's details and was working on it, and told people to update to 7.2.0 and watch its GitHub advisories. It names no fixed build for CVE-2026-102490, and the advisories page we read lists no entry for it.

• Sysdig says 7.0.0 or later is not exploitable for the RCE but still at risk for the LPE, and to watch for a fixed build.

• CISA's catalog entry says to apply vendor mitigations, or discontinue use if none exist.

So we can point to no vendor-confirmed fix for the root escalation. Recheck the Zammad advisories and the DIVD page before every decision.

What to do now

• Inventory every Zammad instance, its version, and its internet exposure.

• Follow DIVD: upgrade to Zammad 7, or take the instance offline. Zammad says 6.5 and older no longer receive security fixes.

• Segment the helpdesk with default-deny egress, as Sysdig advises.

• Keep /var/log/zammad and /var/log/nginx before rebuilding anything, then run DIVD's log check script against them. Sysdig warns that a clean result does not mean a clean host, so look for unfamiliar processes and files too.

• Treat any sign of exploitation as full host compromise, and rotate every credential on or reachable from the host.

Our reading: until a fix for CVE-2026-102490 is named, any foothold on a Zammad host is a potential root event.

How to hunt the activity

Each hunt binds to a behavior DIVD or Sysdig published, or to DIVD's log check. The query text and field names are ours, so every one is marked test first. Run them back to 21 September 2026, DIVD's first-access date, if retention allows.

Credential file reads are published too, but need syscall level telemetry such as auditd. None of these queries sees them, though the Falcon hunt covers Sysdig's find and grep sweeps. The table under the hunts, "Interpret before you escalate", says what is benign and what is not.

Hunt in Splunk: DIVD's log check and sessions that change address (test first)

Search 1: DIVD's log check

index=YOUR_ZAMMAD_LOG_INDEX ("Cookie" OR "@clients")
| regex _raw="ERROR -- :.*(\"Cookie\"=>\"|@clients=\{)"
| stats count min(_time) as first max(_time) as last by host source

Search 2: one session, more than one address

index=YOUR_ZAMMAD_WEB_INDEX
| eval sid=coalesce(session_id, http_session, cookie_session)
| eval client=coalesce(src_ip, clientip, src)
| where isnotnull(sid) AND isnotnull(client)
| stats dc(client) as client_count values(client) as clients min(_time) as first max(_time) as last by sid
| where client_count>1

Field mapping: the first search is DIVD's log check, ERROR lines carrying session material in Zammad and nginx logs. It counts matches and does not print them, so cookies stay out of your results. The second search is ours: map the session and client fields to your web log. Without a session identifier it cannot run.

False positives: phones, VPNs and proxies move users between addresses.

Empty result: confirm Zammad and nginx logs reach this index.

Hunt in Kibana: shells and root children under the app (test first)

event.category: "process" and event.type: "start" and host.name: "YOUR_ZAMMAD_HOST"
and process.parent.name: ("puma" or "ruby" or "bundle")
and (
  process.name: ("sh" or "bash" or "dash" or "curl" or "wget" or "nc" or "su" or "sudo")
  or user.name: "root"
)

Field mapping: the behavior is Sysdig's. The application process should not spawn a shell or download tools, and a root-owned child under it is a signal. The ECS fields and tool list are ours. Puma can retitle itself.

False positives: Zammad's own jobs or admin maintenance.

Empty result: confirm helpdesk process telemetry reaches Elastic.

Hunt in Falcon CQL: shells, tools and filesystem sweeps (test first)

#event_simpleName=ProcessRollup2 event_platform=Lin
| ComputerName="YOUR_ZAMMAD_HOST"
| ParentBaseFileName=/^(puma|ruby|bundle)/i
| FileName=/^(sh|bash|dash|curl|wget|nc|find|grep|su|sudo)$/ or UserName="root"
| table([@timestamp, ComputerName, UserName, ParentBaseFileName, FileName], limit=1000)

Field mapping: the behaviors are Sysdig's, including find or grep sweeps by processes outside the baseline. The fields and regexes are ours. We left CommandLine out because commands can carry secrets.

False positives: scheduled Zammad tasks and admin work.

Empty result: confirm the sensor is on the helpdesk host.

Hunt in KQL: new outbound destinations from the helpdesk (test first)

let Window = ago(7d);
let Baseline = ago(37d);
let Helpdesk = dynamic(["YOUR_ZAMMAD_HOST"]);
let Known = DeviceNetworkEvents
    | where Timestamp between (Baseline .. Window)
    | where DeviceName in~ (Helpdesk)
    | distinct RemoteIP;
DeviceNetworkEvents
| where Timestamp >= Window
| where DeviceName in~ (Helpdesk)
| where ActionType == "ConnectionSuccess" and RemoteIPType == "Public"
| join kind=leftanti Known on RemoteIP
| summarize Connections=count(), First=min(Timestamp), Last=max(Timestamp),
    Processes=make_set(InitiatingProcessFileName, 10) by DeviceName, RemoteIP, RemotePort
| order by Connections desc

Field mapping: Sysdig's behavior is outbound connections to destinations the helpdesk never contacted before. The baseline and fields are ours, and DeviceName must match Defender's host name.

False positives: updates, mail relays and integrations you configured.

Empty result: confirm Defender for Endpoint covers the host and the baseline has data.

Interpret before you escalate

Finding	Benign read	Escalate when
DIVD log check hit	None that DIVD offers	Always. Preserve logs, then triage the host as compromised
One session from two addresses	Phone, VPN or proxy change	The new address sits in another network, soon after login, followed by unusual requests
Shell or download tool under Zammad	A job or admin you can reproduce	It runs a command outside your baseline, or follows another finding here
Root child under the app tree	Maintenance with a change record	No change record, or a shell by zammad came first
New public destination from the helpdesk	An update or integration you set up	It is unfamiliar, carries large uploads, or follows a process hit
Empty results	Nothing matched	Logs, fields or retention are missing, so fix coverage first

Sources

• DIVD case DIVD-2026-00014, When, not if: https://csirt.divd.nl/cases/DIVD-2026-00014/

• DIVD case DIVD-2026-00015, Vulnerabilities in Zammad: https://csirt.divd.nl/cases/DIVD-2026-00015/

• DIVD log check script for CVE-2026-102489: https://csirt.divd.nl/downloads/DIVD-2026-00015/cve-2026-102489_ioc_check_script_v2.sh

• Zammad community thread with the Zammad statements of 1 October 2026: https://community.zammad.org/t/take-care-local-privilege-escalation-cve-2026-102490-is-reported-as-being-actively-exploited/21297

• Zammad security advisories: https://github.com/zammad/zammad/security/advisories

• CISA alert, 2 October 2026: https://www.cisa.gov/news-events/alerts/2026/10/02/cisa-adds-two-known-exploited-vulnerabilities-catalog

• CISA Known Exploited Vulnerabilities Catalog (due date 2026-10-05): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

• Sysdig, AI agent exploits Zammad zero-days in DIVD breach, 2 October 2026: https://www.sysdig.com/blog/ai-agent-exploits-zammad-zero-days-in-divd-breach-what-we-know-and-how-to-detect-it

• SecurityWeek, 1 October 2026: https://www.securityweek.com/zammad-zero-days-exploited-in-ai-powered-divd-hack/

What This Means for Your Team

Find every Zammad instance you run and note its version and exposure. Upgrade to Zammad 7 or take exposed instances offline, preserve the logs, and run DIVD's check. Then check the Zammad advisories again for CVE-2026-102490, because that answer is still moving. If anything matches, treat the host as compromised and rotate what it could reach.

Inception Protection

Inception Protection is our managed detection and response service, and it works with the Microsoft licenses you already have. A helpdesk host only helps us if its logs and process data reach us, so we start there. Then we read it next to your identity and endpoint signals as one story, and you keep the decisions.

Inception Foresight

If you want to see how well your Microsoft environment would surface activity like this, the free Inception Foresight M365 Assessment is a good place to start: https://www.inceptionsecurity.com/m365assessment. You can also follow Inception Security on LinkedIn and @inceptionsec on X.