Inside CVE-2026-102489: The Zammad Session Hijack That Ends in Code Execution

CVE-2026-102489 is the entry point of a two-stage attack on Zammad deployments. NCSC-NL describes it as a vulnerability that lets an unauthenticated remote attacker run arbitrary code. DIVD classifies it more precisely as a session hijack that leads to remote code execution as the zammad user. This article focuses on that mechanism and the conditions that make it reachable.

The affected range

According to DIVD, Zammad versions 6.3.0 through 6.5.4 are vulnerable. The vulnerable behaviour is also present in versions 7.0.0 through 7.1.3, but DIVD states it is not exploitable there because of environment conditions in those releases. That distinction is important for triage: a version that contains the code is not automatically a version that can be exploited.

NCSC-NL assigns CVE-2026-102489 a CVSS v4 base score of 9.4 and lists it alongside CVE-2026-102490, which carries the same score.

What session hijacking means here

Session hijacking is a class of flaw in which an attacker obtains the ability to act inside an existing authenticated session, or to create the appearance of one, without going through a legitimate login. The canonical CWEs are CWE-384 (session fixation) and CWE-287 (improper authentication).

In an application like Zammad the practical consequence is severe. Agents hold meaningful privileges: they read and write tickets across queues, download attachments, trigger outbound email, and often access integrated knowledge bases. An attacker operating inside an agent session inherits all of that without ever supplying a password or a second factor.

From session control to code execution

The step beyond session control is where CVE-2026-102489 becomes a code execution issue rather than a data disclosure issue. Zammad is a Ruby on Rails application deployed behind a web server, with a background job processor and a database. It ships with administrative functionality that can influence server-side behaviour: integrations, webhooks, triggers, schedulers and template rendering.

When an attacker can act as an administrative agent, those features stop being administrative conveniences and become execution primitives. A webhook or scheduler definition that reaches an external resource, a template that evaluates server-side logic, or an integration credential that grants access to a connected system can each be turned into a step toward running commands as the zammad user.

DIVD's wording is the authoritative summary: the vulnerability is a session hijack that leads to remote code execution as the zammad user. The public advisories do not publish a proof of concept, which is normal for a zero-day that was exploited in the wild before disclosure.

Exploitation conditions

Three conditions shape the practical risk profile.

First, network reachability. The vulnerable code path is part of the web application, so an instance must be reachable for the unauthenticated step to be attempted from outside. Publicly exposed Zammad deployments are the primary concern.

Second, version. Versions 6.3.0 to 6.5.4 are directly affected. Later 7.0.x and 7.1.x releases contain the affected behaviour but are reported as not exploitable in their default environment configuration, so an upgrade changes the exploitability picture even before a dedicated fix is confirmed.

Third, surrounding configuration. Whether code execution is reachable depends on which application features are enabled, how the web server routes requests, and what the zammad service account can reach. A hardened deployment with tight egress rules and no host mounts constrains what the attacker can do after the session is taken.

Why this class of bug is underrated

Session handling flaws are frequently triaged as medium severity because they are described in terms of access to an existing account. That framing breaks down when the application itself executes code, orchestrates background jobs and connects to other systems.

There is also a detection problem. A hijacked session may look entirely legitimate in application logs: correct user, correct role, valid cookies. The anomaly usually appears in network telemetry or in the absence of a corresponding authentication event, not in the application's own audit trail.

Indicators to look for

Organisations running Zammad should examine records from 21 September 2026 onward for:

• Agent sessions with no matching authentication entry in the same log stream.
• Sessions whose client IP or user agent changes between requests.
• Administrative actions taken by accounts that were offline or unaware at the time.
• New or modified webhooks, triggers, schedulers and integrations.
• Unusual outbound connections originating from the Zammad host.
• Unexplained processes whose parent is the Zammad application or job runner.

DIVD provides a verification script that scans Zammad log files for indicators of compromise. Retaining the logs is a prerequisite for using it, which is why both NCSC-NL and DIVD advise preserving application and network logs before installing updates.

Remediation

NCSC-NL states that Zammad released security updates addressing CVE-2026-102489 and recommends installing them urgently. DIVD recommends upgrading to Zammad version 7 or taking the instance offline while a fix is arranged.

The ordering matters. Collect logs first, snapshot the host if policy allows, then patch. Installing the update stops new exploitation but cannot establish whether the system was already accessed.

Defensive controls that limit this class of flaw

Because CVE-2026-102489 is only one instance of a general pattern, the durable controls are architectural:

• Bind agent sessions to additional context such as client certificate, device posture or IP range where operational constraints allow.
• Enforce short session lifetimes and re-authentication for administrative actions.
• Require multi-factor authentication for all agent accounts, which does not stop a hijack but shortens the window during which a stolen session is the only barrier.
• Run the application under a dedicated, unprivileged account with a restrictive seccomp profile and no host filesystem mounts.
• Restrict egress from the application host to explicitly required destinations.
• Monitor for session anomalies centrally rather than relying on the application's own logs.

Conclusion

CVE-2026-102489 is a reminder that authentication boundaries are enforced by session logic, and that session logic is application code. When that code can be subverted, the entire privilege model of the platform collapses into whatever the service account can reach.

The immediate action is to inventory Zammad deployments, prioritise versions 6.3.0 to 6.5.4, preserve logs, and upgrade. The longer-term action is to treat a helpdesk platform as what it is: an internet-facing system of record that deserves segmentation, egress control and continuous monitoring.

Sources

• NCSC-NL advisory NCSC-2026-0396 (CVE-2026-102489, CVE-2026-102490).
• DIVD case DIVD-2026-00015.
• Zammad vendor security advisory index.