Session hijacking enables remote code execution in Zammad by Zammad GmbH

Zammad versions 6.3.0 to 6.5.4 are vulnerable a session hijack vulnerability that leads to remote code execution as the zammad user. The bug is also present in version 7.0.0 to version 7.1.2, but not exploitable due to changes in the underlying framework.

• DIVD's CNA page lists the affected deployment as Zammad on Linux or Docker with >= 6.3.0 and < 6.5.4.
• The supplied base description separately says 6.3.0 through 6.5.4, which conflicts with the CNA's structured < 6.5.4 boundary. The status of 6.5.4 should therefore not be inferred as safe or affected from the base description alone.
• DIVD's later case page lists 7.0.0 through 7.1.3 as containing the issue but not exploitable because of environment conditions. Zammad's advisory says 7.0 and later are not affected in practice, while the hardening change is included in 7.2.0.
• Versions below 6.3.0 and branches outside these entries are not fully established as affected by the CNA evidence.

Zammad by Zammad GmbH is described as having a session hijacking flaw, mapped by the CNA data to CWE-384, Session Fixation. An attacker who can reach the service over the network may obtain or reuse a valid session and reach code execution as the zammad service account; the available evidence does not disclose the exact session input, endpoint, or execution sequence. The supplied assessment indicates that no prior privileges are required. The user interaction requirement is not fully resolved: one assessment records passive interaction while another records none. According to Zammad, exploitation depends on the runtime environment used by older branches; later branches may retain related code but are reported as not exploitable in practice. The precise boundary between code presence and practical exploitability should therefore be checked against the affected_summary and vendor guidance.

• Reachability: The Zammad service can be reached over the network.
• Privileges: The supplied assessment indicates that no prior privileges are required.
• User interaction: The assessments are inconsistent, recording either passive interaction or no interaction; the exact condition is not established.
• Exploitation status: The record marks the vulnerability as exploited and identifies a public exploit. DIVD reports that the vulnerability was abused to breach one of its Zammad systems and was then analyzed and reproduced. DIVD also reports scanning publicly accessible vulnerable Zammad instances.
• Public evidence does not provide enough detail to describe a specific payload or exploit sequence.

The flaw enables remote code execution with the permissions of the zammad service account, directly affecting the confidentiality, integrity, and availability of data that account can access. Within the application's permission boundary, an attacker may read or modify support data, change configuration, or disrupt service. The available evidence does not show that the flaw alone grants operating-system administrator or root access; escalation beyond the service account depends on deployment configuration and additional weaknesses. DIVD's report of successful exploitation increases the risk for exposed instances beyond that of a purely theoretical defect.

• Successful exploitation can run code as the zammad service account, potentially exposing or changing tickets, attachments, configuration, and other data accessible to that account.
• The flaw can enable service disruption or persistence within the application's permission boundary.
• The available evidence does not establish root or full host control from this flaw alone; broader impact depends on deployment permissions and additional weaknesses.
• Because exploitation has been reported, exposed instances should be treated as potentially compromised, not merely unpatched.

1. Upgrade to Zammad 7.2.0, which the vendor identifies as containing the additional hardening change. Do not interpret this as proof that every parallel branch is covered unless the vendor confirms it separately.
2. If running a branch identified in affected_summary and unable to upgrade immediately, take the instance offline as DIVD advises.
3. If still using Zammad 6.5 or older, update immediately. The vendor states that these releases are unsupported and no longer receive security updates.
4. After containment or upgrade, use DIVD's log-check script and supplied indicators to assess possible compromise. Preserve logs and other evidence before cleaning up or rebuilding the instance.
5. Restrict access to the underlying Zammad server to trusted administrators while remediation is in progress.

1. Inventory every Zammad instance, including its installed release, installation form, runtime environment, and network exposure.
2. Compare each installed release with the exact boundaries in affected_summary; do not assess safety from the major version alone.
3. Review Zammad logs with the log-check script and indicators provided by DIVD. The available record does not name specific log events, so do not invent IOC patterns.
4. Investigate unusual session activity and unexplained code execution on Internet-facing instances. Treat these as triage leads, not confirmed indicators.
5. A clean log review does not prove safety if logs were deleted, are incomplete, or were never collected.