CVE-2026-56728 in Zammad
Summary
by MITRE • 09/25/2026
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, a broken access control vulnerability exists in Zammad's GraphQL API. An authenticated user can access taskbar item data belonging to another user by crafting a request with the target user's taskbar identifier. The taskbar feature stores transient state for active user sessions, including auto-saved ticket drafts. Under certain conditions, the authorization check for taskbar item access is not enforced, allowing a user to read another user's taskbar item data. This vulnerability is fixed in 7.0.2.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
Zammad serves as a prominent open-source helpdesk and customer support platform designed to manage complex ticketing workflows across distributed teams. Within this ecosystem, the GraphQL API provides a flexible interface for clients to query and mutate data, enabling efficient retrieval of specific information without over-fetching or under-fetching resources. However, prior to version 7.0.2, a critical security flaw was identified within the implementation of the taskbar feature via this GraphQL endpoint. The vulnerability stems from broken access control mechanisms that fail to properly validate whether the authenticated user initiating the request is the legitimate owner of the requested resource. This specific weakness allows an attacker who has valid credentials for one account to manipulate API requests by substituting identifiers associated with other users, thereby bypassing intended authorization boundaries.
The technical root cause lies in how the application handles object-level permissions during GraphQL query execution. The taskbar functionality is designed to store transient state data relevant to active user sessions, which includes sensitive operational details such as auto-saved ticket drafts and personalized interface configurations. When a user requests access to their taskbar items, the backend logic must verify that the identifier provided in the request corresponds exclusively to the session of the authenticated principal. In vulnerable versions, this authorization check is either missing or incorrectly implemented for specific GraphQL resolvers handling taskbar data. Consequently, an attacker can craft a malicious GraphQL query containing the target user's unique taskbar item identifiers. Since the server does not strictly enforce ownership validation against the current authentication context, it processes the request and returns the associated private data to the requester as if they were the legitimate owner of that session state.
The operational impact of this vulnerability is significant due to the nature of the exposed data. Taskbar items often contain auto-saved ticket drafts which may include confidential customer information, internal notes, or preliminary troubleshooting steps intended only for the assigned agent. By exploiting this flaw, an authenticated user can perform unauthorized data exfiltration, reading sensitive content belonging to colleagues without their knowledge. This represents a clear violation of confidentiality principles and undermines trust within collaborative support environments where multiple agents share access to the same instance but maintain distinct operational boundaries. The ability to view another user's drafts could also facilitate social engineering attacks or provide contextual intelligence for further exploitation attempts against specific individuals or departments.
This vulnerability is classified under CWE-284, which describes Improper Access Control, specifically highlighting failures in authorization checks that allow users to access resources they should not be permitted to see. From a tactical perspective aligned with the MITRE ATT&CK framework, this behavior corresponds to techniques involving unauthorized data access through API endpoints, often categorized under Initial Access or Discovery phases depending on whether it is used for reconnaissance or direct theft of credentials and sensitive documents. The flaw underscores the importance of rigorous input validation and strict object-level permission checks in GraphQL implementations, where the flexibility of query structures can sometimes obscure underlying authorization logic if not carefully audited.
To mitigate this risk, organizations running Zammad must upgrade to version 7.0.2 or later, which contains patches that enforce proper ownership verification for taskbar item requests. Until an update is applied, administrators should monitor API logs for unusual patterns of access where a single user account frequently queries resources associated with different identifiers, although such detection may be challenging without detailed audit trails. Furthermore, developers implementing custom GraphQL extensions in Zammad environments should ensure that all resolvers explicitly validate the relationship between the authenticated session and the requested resource ID to prevent similar broken access control issues from emerging in other parts of the application logic.