Table of contents
20
Read this in 30 seconds: CVE-2026-102489 and CVE-2026-102490 are two Zammad helpdesk bugs that chain from a remote session hijack to root, and CISA says both are being exploited.
- The chain is two bugs. CVE-2026-102489 is a session hijack that leads to code execution as the
zammaduser, with no login. CVE-2026-102490 is a local escalation from that user to root.- We know about it because a security nonprofit got breached. The Dutch Institute for Vulnerability Disclosure (DIVD) says an attacker used the chain against its own Zammad on September 21, and that the intrusion looked like an autonomous AI agent.
- The technical details are withheld. DIVD hasn’t published how either bug works, and we couldn’t find the fix in Zammad’s public code, so this article doesn’t pretend to show you vulnerable code.
- The vendor and the finder disagree. On which versions are exposed, on disclosure timing, and on whether CVE-2026-102490 is confirmed at all.
- Safest move: upgrade to Zammad 7.2.0, then hunt. CISA added both CVEs to KEV on October 2 with a three-day deadline and a forensic-triage flag.
A helpdesk is where a company keeps its customers’ complaints, contracts and credentials, and a two-bug chain that reaches root there turns a support queue into a foothold.
CVE-2026-102489 was published on September 30, 2026, by DIVD, the same organization that found it by reverse engineering an attack on itself. CISA added it and its companion to the Known Exploited Vulnerabilities catalog two days later, with a due date of October 5.
Here’s what’s actually public about CVE-2026-102489, where the sources contradict each other, and what to check on your own Zammad.
Zammad is an open-source ticketing and helpdesk platform, available self-hosted or as a service. Teams run it for customer support and IT service desks, and per Sysdig’s analysis DIVD used it for CSIRT ticketing. That means its database holds customer messages, attachments, contact details and often the integrations that connect to mail, chat and other systems.
A foothold there is worth more than the product’s size suggests. An attacker who lands on the Zammad host can read everything agents can read, and anything else the server can reach.
CVE-2026-102489 and its companion are separate bugs that DIVD and CISA both describe as chainable:
| CVE-2026-102489 | CVE-2026-102490 | |
|---|---|---|
| What it is | Session hijack leading to remote code execution as the zammad user | Local privilege escalation from the zammad user to root |
| CWE | CWE-384 (session fixation) | CWE-269 (improper privilege management) |
| Needs | Network access, no credentials | Code execution on the server already |
| Affected (NVD) | 6.3.0 to 6.5.4, plus 7.0.0 to 7.1.3 | 1.5.0 up to 7.1.0, plus the 7.1.0 alpha |
| Fix status | Zammad says hardened in 7.2.0 | No fix identified |
Both carry an NVD CVSS 3.1 score of 9.8 (AV:N/AC:L/PR:N/UI:N), and DIVD’s own CVSS 4.0 vector scores both 9.4. Those two numbers describe the chain, not the second bug alone.
That’s worth saying out loud, because CVE-2026-102490 is a local bug. Zammad’s fliebe92, posting on its community forum, states it plainly: “This issue cannot be exploited remotely on its own. An attacker would already need access to your server.” A 9.8 on a bug that needs prior code execution only makes sense as a chain score.
CISA’s SSVC data adds one more signal: active exploitation, with CVE-2026-102489 marked automatable. CVE-2026-102490 is not, which fits a bug that only matters after the first one lands.
Here’s the part to be precise about, because most coverage isn’t. No source has published the mechanism of CVE-2026-102489 or its companion. DIVD’s case page describes CVE-2026-102489 only as a “session hijack vulnerability that leads to remote code execution as the zammad user,” and the CVE record repeats that sentence. CVE-2026-102490 is described in one line.
What the sources do confirm, from DIVD and from Sysdig’s analysis of it:
zammad service user through the session bug, with no credentials.There’s one more clue, and it’s a small one. DIVD’s CVSS 4.0 vector for CVE-2026-102489 includes UI:P, passive user interaction. That would fit a session-fixation flaw, where the victim’s own login completes the attack. But that’s our reading of one metric, not something DIVD has stated.
The most revealing artifact is DIVD’s IOC check script. Its core is a single search over Zammad and nginx logs:
zgrep -En 'ERROR -- :.*("Cookie"=>"|@clients=\{)' /var/log/zammad/* /var/log/nginx/*It looks in production.log, railsserver.log, websocket.log, scheduler.log and the nginx logs for error lines that contain cookie values or what looks like websocket client state. Matches mean session material is showing up in error output.
We don’t know from the script alone why exploitation leaves that trace. A reasonable guess is that the attack path triggers an error that dumps request headers and connection state into the logs. That’s inference from what the script searches for, not something DIVD has said.
Zammad is open source, so we looked. We pulled Zammad’s public history between 7.1.3 and 7.2.0, 241 commits, and found nothing identifiable as the fix. 7.2.0’s release commit is dated September 23, and Zammad says the change is in that release.
One nearby commit is easy to mistake for it. An October 1 change to Zammad’s file session store is a race-condition fix for websocket sessions getting lost on login. It is a reliability fix, not the security patch, and treating it as one would be a guess.
So we’re not going to reconstruct code for a bug nobody has described. If DIVD or Zammad publishes the mechanism, this section is the one that changes.
The disclosure of CVE-2026-102489 is unusually messy, and the disagreement matters for what you do next.
| Question | DIVD | Zammad |
|---|---|---|
| Is Zammad 7.x exposed to CVE-2026-102489? | Present in 7.0.0 to 7.1.3 but “not exploitable due to environment conditions” | “Zammad 7.0 and later are not affected” |
| What should you upgrade to? | “Version 7 of Zammad or to take it offline” | 7.2.0, the current stable release |
| Is CVE-2026-102490 confirmed? | Affects all versions, including the latest alpha | “We cannot confirm the vulnerability, its scope or the affected versions” |
| Disclosure | Reported September 24, public scanning and disclosure September 26 | DIVD gave no technical details on CVE-2026-102490, yet a CVE ID was published for it |
Zammad’s staff add two facts of their own. They say they first received a report about the session issue in August 2026 and analyzed it then, and that the fix shipped in 7.2.0, whose release commit predates DIVD’s September 24 report. DIVD’s attack on September 21 happened before 7.2.0 existed.
Read together, the sources agree on the practical answer even where they disagree on the details. Versions 6.5.4 and older are exploitable for CVE-2026-102489. Anything on 7.x is either unaffected or not exploitable. 7.2.0 satisfies everyone’s guidance.
DIVD’s headline claim is that an autonomous AI agent ran the intrusion. The evidence it offers is behavioral. The agent was “loud and very messy,” decided each next step itself at machine speed, and left comments in its own scripts explaining why what it was doing was acceptable, which DIVD says a human attacker wouldn’t bother to write.
That’s DIVD’s assessment, and Sysdig’s analysis calls it inferred from operational patterns rather than from any attribution. Nobody has identified who or what was behind it.
The defensive takeaway doesn’t depend on settling that. The chain went from no credentials to root in seconds, and the first sign of trouble was a messy intrusion DIVD noticed the next day. When both bugs are available, a defender has no window to react between the stages, so the controls that matter are the ones already in place: patching, segmentation and logging. We cover the offensive side in our piece on autonomous AI hacking agents.
You’re exposed if both of these are true:
CVE-2026-102490 is a different question: it needs code execution first, so it only matters after the first bug or any other foothold.
zammad user can reach.Start with DIVD’s search for CVE-2026-102489 above. Then use Sysdig’s detection guidance for each stage of the chain:
zammad user, new root-owned child processes under the application tree, and writes to privileged paths by that account.If anything matches, treat it as confirmed compromise. Preserve /var/log/zammad and /var/log/nginx before you rebuild anything, since CISA’s forensic-triage guidance calls for evidence preservation first. A clean search doesn’t clear you: DIVD’s script only finds one trace of one stage.
The lesson in CVE-2026-102489 isn’t the specific flaw, which nobody has described. It’s that session handling and privilege boundaries are two places where bugs chain, and each stage looks modest on its own. A session flaw that yields a service-user shell, plus a local escalation, is a full compromise from two bugs that individually might be triaged as medium.
A pentest that validates chains, not isolated findings, is how you’d find that before an attacker does. We’d test a pre-authentication session for fixation and reuse across login, then ask what a shell as the application user can reach on the host. Our AI VAPT services piece covers how that kind of chained validation works.
The other thing this case shows is why the forensic step matters. We make the same point about the Arista VeloCloud bug CISA also flagged for forensics: patching closes the door, but it doesn’t tell you who already walked through it.
CVE-2026-102489 is a Zammad session-fixation vulnerability (CWE-384) that lets an unauthenticated attacker hijack a session and execute code as the zammad service user. It affects Zammad 6.3.0 to 6.5.4, and DIVD says it’s also present but not exploitable in 7.0.0 to 7.1.3. NVD scores it 9.8.
Yes. DIVD says it was used against DIVD itself on September 21, 2026, chained with CVE-2026-102490, and CISA added both to the Known Exploited Vulnerabilities catalog on October 2 with a due date of October 5.
CVE-2026-102490 is a local privilege escalation that lets the zammad user become root. DIVD says it affects every Zammad version from 1.5.0 through the 7.1.0 alpha. Zammad says it can’t confirm the vulnerability, and that it can’t be exploited remotely on its own.
Upgrade to Zammad 7.2.0, which Zammad says includes the change that hardens the vulnerable code. If you can’t upgrade, DIVD advises taking Zammad offline. Then check your logs for compromise before assuming the upgrade was enough.
NVD lists 6.3.0 through 6.5.4 as exploitable and 7.0.0 through 7.1.3 as affected but, per DIVD, not exploitable. Zammad says 7.0 and later are not affected and that CVE-2026-102489 is only exploitable on 6.5 and older.
We couldn’t identify one. DIVD’s guidance is to upgrade to version 7 or go offline, and neither source offers a specific mitigation for the escalation.
DIVD says it did, based on how the attacker behaved: machine-speed steps and self-explaining comments in its scripts. Sysdig calls that an inference from operational patterns. No one has publicly attributed the attack.
CVE-2026-102489 is a case where the practical advice is clear even though the technical story isn’t. Upgrade to 7.2.0, take Zammad offline if you can’t, and run DIVD’s log search plus Sysdig’s detection list before you decide the upgrade was enough.
What you shouldn’t do is trust any write-up that claims to show you exactly how the bugs work. Nobody has published that yet, including us. When the mechanism does come out, the interesting part will be how a session flaw ended up one local escalation away from root.
Categories
Related articles
