CVE-2026-56726 in Zammad
Summary
by MITRE • 09/25/2026
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, this vulnerability breaks normal ticket isolation boundaries between agents. Any authenticated agent, even one with no active tickets assigned to them, can view the titles, status, labels, and URL links of GitHub/GitLab issues attached to any ticket in the system. This allows an internal user to systematically view GitHub/GitLab issue data linked by other agents or administrators across the organization by simply querying random or sequential ticket IDs. This vulnerability is fixed in 7.0.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
Zammad serves as a prominent open-source helpdesk and customer support platform, facilitating communication between organizations and their customers through structured ticketing systems. In versions prior to 7.0.2, the application exhibited a critical flaw related to access control enforcement within its integration with external issue tracking platforms such as GitHub and GitLab. The core of this vulnerability lies in the failure to properly enforce isolation boundaries for data associated with linked third-party issues when accessed by authenticated agents. While Zammad is designed to restrict visibility based on ticket assignment and organizational roles, the specific implementation handling references to external repositories did not adequately validate whether the requesting user had legitimate authorization to view metadata from those external sources attached to other tickets.
The technical flaw allows any authenticated agent, regardless of their current workload or assigned ticket status, to access sensitive information linked via GitHub or GitLab integrations. Specifically, an attacker can retrieve titles, statuses, labels, and direct URL links for issues that are associated with tickets they do not own nor have permission to view. This occurs because the API endpoints or frontend components responsible for rendering these external references did not perform sufficient authorization checks against the underlying ticket ownership rules before returning data from the integrated platforms. Consequently, an internal user can systematically enumerate and extract this information by querying random or sequential ticket identifiers, effectively bypassing the intended security model that separates agent workloads and confidential customer interactions.
The operational impact of this vulnerability is significant for organizations relying on Zammad to manage sensitive support operations involving software development lifecycles. By exposing GitHub and GitLab issue data across organizational boundaries, internal users can gain insights into ongoing projects, bug reports, feature requests, or security patches that were intended to be visible only to specific teams or administrators. This unauthorized disclosure constitutes a breach of confidentiality and may lead to information leakage regarding proprietary software development activities. Furthermore, the ability to map ticket IDs to external issue URLs could facilitate further reconnaissance, allowing an attacker to correlate internal support metrics with public repository activity, potentially identifying vulnerabilities in the organization's own codebase before they are publicly disclosed or patched.
This vulnerability is classified under CWE-284, which describes Improper Access Control, as it involves a failure to restrict access to resources based on user privileges. Additionally, from an offensive security perspective aligned with MITRE ATT&CK frameworks, this behavior corresponds to techniques such as T1078 Valid Accounts and potentially T1539 Steal Web Session Cookie if session hijacking were involved, though primarily it represents a direct exploitation of broken access control principles (T1528). The vulnerability enables an authenticated user to escalate their effective visibility beyond their assigned scope without requiring privilege escalation in the traditional sense.
To mitigate this risk, organizations running Zammad must upgrade immediately to version 7.0.2 or later, where the issue has been resolved through stricter enforcement of access control checks on external reference data. Until upgrading is possible, administrators should review agent permissions and consider limiting direct API exposure for ticket-linked resources if feasible. Regular audits of user roles and adherence to the principle of least privilege are essential practices to minimize the blast radius of such internal access control failures within helpdesk environments.