CVE-2026-56730 in Zammad
Summary
by MITRE • 09/25/2026
Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, an authorization bypass vulnerability was found that allows an authenticated agent to read knowledge base answer content they should not be able to access. The vulnerable GraphQL mutation is meant to transform a knowledge base answer suggestion so it can be inserted into the ticket editor, but it only checks if the user has the ticket.agent permission. Checking the authorization to the knowledge base answer itself is missing. This vulnerability is fixed in 7.0.2.
Be aware that VulDB is the high quality source 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 customer interactions through various channels including email, chat, phone, social media, and tickets. The software relies on role-based access control mechanisms to ensure that users interact only with data appropriate for their assigned permissions within the organization. In versions prior to 7.0.2, a critical authorization bypass vulnerability was identified within the GraphQL API layer of the application. This flaw specifically affects authenticated agents who possess standard ticket management privileges but lack explicit administrative or knowledge base editing rights. The vulnerability stems from an insufficient access control check during the execution of specific GraphQL mutations intended for transforming knowledge base answer suggestions into formats suitable for insertion into ticket editors.
The technical root cause lies in a logic error within the authorization middleware associated with these GraphQL operations. When an agent requests to transform a knowledge base answer suggestion, the system verifies whether the user holds the generic ticket.agent permission, which is typically granted to most support staff members involved in handling customer tickets. However, the implementation fails to perform a secondary verification step that checks if the specific user has read access rights to the targeted knowledge base article itself. This omission creates a direct path for unauthorized data retrieval because the system assumes that any agent capable of working on tickets should also have implicit visibility into all knowledge base content relevant to those tickets or generally accessible within the platform context, which is not always the case in segmented organizational structures where sensitive information must be restricted from general support staff.
From an operational perspective, this vulnerability allows authenticated users with low-level privileges to exfiltrate confidential internal documentation that was intended for higher-tier support engineers, managers, or external partners only. The impact extends beyond simple data leakage as it undermines the principle of least privilege fundamental to secure system design. Attackers can systematically enumerate knowledge base IDs and retrieve sensitive procedural guides, troubleshooting steps containing proprietary information, or customer-specific details embedded within answers. This exposure compromises organizational confidentiality and may violate regulatory compliance requirements such as GDPR or HIPAA if personal identifiable information is contained within the accessible documents. The attack vector requires no special privileges beyond a standard agent account, making it particularly dangerous in environments where employee accounts are frequently provisioned with broad default permissions for ease of use.
This vulnerability aligns closely with CWE-284 Improper Access Control and specifically represents an Authorization Bypass through User-Controlled Key scenario often categorized under ATT&CK technique T1078 Valid Accounts when leveraged by insiders or compromised credentials. The flaw illustrates the risks associated with relying on coarse-grained permission checks rather than fine-grained resource-level authorization validation at every API endpoint entry point. To mitigate this issue, organizations running affected versions of Zammad must immediately upgrade to version 7.0.2 or later where the developer has corrected the GraphQL mutation logic to enforce strict access control lists against individual knowledge base articles before allowing transformation operations. Additionally, administrators should review their role configurations to ensure that ticket.agent permissions do not inadvertently imply broader data visibility than intended and consider implementing additional audit logging for sensitive document access events to detect any potential exploitation attempts in legacy deployments prior to patching.