CVE-2026-84460 in Zammad
Summary
by MITRE • 09/25/2026
Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, any authenticated user can call the REST endpoint for getting a tag list and receive the tag names for the given ticket, regardless of whether they have access to that ticket. Tags are an internal categorization feature and may contain sensitive labels. Ticket IDs are sequential integers, making bulk enumeration straightforward. This issue is fixed in version 7.1.2.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in Zammad prior to version 7.1.2 represents a critical failure in access control mechanisms within the application's REST API layer. As an open-source helpdesk and customer support system, Zammad handles sensitive organizational data, including internal ticket categorizations known as tags. These tags serve as internal labels that may contain confidential information regarding incident severity, departmental ownership, or specific business logic classifications. The core technical flaw lies in the authentication middleware's inability to properly validate user permissions against the resource being accessed via the tag retrieval endpoint. While the system correctly requires users to be authenticated before accessing any API resources, it fails to perform an authorization check that ensures the authenticated user has explicit permission to view the specific ticket associated with the requested tags. This oversight allows any logged-in account to bypass role-based or object-level security controls by simply providing a valid ticket identifier in the request payload.
From a technical perspective, this is a classic example of Insecure Direct Object Reference (IDOR), categorized under CWE-639. The vulnerability exploits the predictable nature of the underlying database schema where ticket identifiers are implemented as sequential integers. This design choice significantly lowers the barrier for exploitation because an attacker does not need to discover random or complex UUIDs to enumerate resources. Instead, they can iterate through integer values in a straightforward manner, systematically requesting tag lists for consecutive ticket IDs. The REST endpoint responsible for this operation accepts these identifiers without verifying whether the session's associated user identity is linked to that specific ticket record in the backend database. Consequently, the application returns sensitive metadata regardless of the requester's actual access rights or departmental boundaries within the helpdesk structure.
The operational impact of this vulnerability extends beyond simple data leakage. By enumerating tag names across a range of tickets, an attacker can map out the internal categorization scheme used by the organization. This intelligence gathering phase is particularly dangerous because it reveals how incidents are classified internally, potentially exposing high-priority issues, security-related complaints, or sensitive customer interactions that were never intended for broad visibility within the user base. Furthermore, since ticket IDs are sequential, an attacker can perform bulk enumeration to harvest a large volume of these internal labels efficiently. This capability transforms what might have been a minor information disclosure into a significant reconnaissance vector, enabling further targeted attacks against specific high-value tickets or allowing adversaries to understand organizational workflows and priorities based on the frequency and nature of tag usage.
This behavior aligns with several techniques documented in the MITRE ATT&CK framework for enterprise environments. Specifically, it corresponds to T1087 Account Discovery, as attackers can infer user roles or groups from tags assigned by administrators, and T1539 Steal Web Session Cookie if combined with other vectors, though primarily it falls under data exfiltration via API abuse. The lack of proper object-level permission checks is a common pitfall in web applications that prioritize ease of development over rigorous security validation at the resource access layer. Attackers can leverage automated scripts to iterate through thousands of ticket IDs rapidly, extracting tag lists and building a comprehensive map of internal operations without triggering typical anomaly detection systems designed for brute-force login attempts rather than authorized API abuse.
Mitigation strategies must focus on enforcing strict authorization checks at every point where external data is used to query sensitive resources. For Zammad users running versions prior to 7.1.2, the immediate remediation is to upgrade to version 7.1.2 or later, which addresses this logic flaw by implementing proper permission validation before returning tag data. In environments where upgrading is not immediately feasible, network-level controls such as Web Application Firewalls (WAFs) can be configured to monitor for patterns indicative of sequential ID enumeration, although this may result in false positives if legitimate users frequently access adjacent tickets. Additionally, developers should review all API endpoints that accept resource identifiers and ensure they implement object-level authorization checks against the current user's permissions database. Changing ticket IDs from sequential integers to non-sequential Universally Unique Identifiers (UUIDs) can also mitigate enumeration risks by increasing the computational cost for attackers attempting to discover valid resources through brute force, although this does not replace the need for proper access control validation.