CVE-2026-84464 in Zammad
Summary
by MITRE • 09/25/2026
Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, zammad's External Data Source feature, used to look up records from an external system, did not properly verify whether a user was allowed to see a specific ticket, user, group, or organization before including its details in a request to that external system. An authenticated user, including one with only basic customer access, could exploit this by referencing another record's ID, and thereby view details of tickets, customer accounts, teams, or organizations that did not belong to them. This issue is fixed in version 7.1.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified within Zammad versions prior to 7.1.2 represents a critical failure in access control logic for the External Data Source feature. As an open-source helpdesk and customer support platform, Zammad relies on strict isolation of data between different user roles, particularly distinguishing between administrative staff and basic customers who should only have visibility into their own tickets and related information. The flaw resides in how the system handles requests to external systems via this integration point. When a user triggers an action that utilizes the External Data Source feature, the application constructs a request containing identifiers for specific records such as tickets, users, groups, or organizations. However, the implementation failed to perform adequate authorization checks prior to including these details in the outbound request. This means that while the internal UI might correctly restrict what a user can see on their screen, the backend logic processing external integrations did not enforce the same boundaries, allowing sensitive data to be exposed through API calls or webhook payloads intended for third-party services.
From a technical perspective, this is a classic example of an Insecure Direct Object Reference vulnerability where the application trusts client-supplied identifiers without verifying that the requesting user has permission to access those specific objects. An authenticated attacker, even one with minimal privileges such as a basic customer account, could manipulate the input parameters sent to the External Data Source mechanism. By substituting standard record IDs with those belonging to other entities within the system, the attacker forces Zammad to retrieve and transmit private information about unrelated tickets, customer accounts, teams, or organizational structures. This bypasses the intended role-based access control model because the validation occurs too late in the request lifecycle or is entirely absent for this specific feature path. The consequence is that confidential business data, potentially including personally identifiable information of other customers or internal operational details, could be exfiltrated to an external system controlled by a third party or intercepted if the connection is not sufficiently secured.
The operational impact of this vulnerability extends beyond simple data leakage. It undermines the fundamental trust model of the helpdesk software, where confidentiality and integrity are paramount for customer support operations. If sensitive ticket contents containing proprietary information or personal data are sent to external systems without proper authorization checks, it could lead to significant regulatory compliance issues under frameworks such as GDPR or HIPAA, depending on the nature of the data involved. Furthermore, this flaw enables horizontal privilege escalation in terms of data visibility, allowing lower-privileged users to gather intelligence about higher-level organizational structures and ongoing support cases that they should not be aware of. This information could subsequently be used for targeted social engineering attacks against employees or other customers whose details were exposed through these unauthorized lookups.
To mitigate this risk, organizations running Zammad must immediately upgrade to version 7.1.2 or later, where the developers have implemented proper authorization checks within the External Data Source feature logic. Until an upgrade is feasible, administrators should consider disabling the External Data Source integration if it is not strictly required for business operations, thereby removing the attack vector entirely. Additionally, reviewing audit logs for unusual patterns of external API calls originating from low-privileged accounts can help identify potential exploitation attempts in environments where patching has been delayed. It is also advisable to ensure that any external systems receiving data via this feature are configured with strict input validation and encryption protocols to minimize the impact if a breach occurs. This incident highlights the importance of implementing consistent security controls across all application pathways, including those interacting with third-party integrations, ensuring that authorization checks are applied uniformly regardless of the entry point used by an authenticated user.