zammad

An issue was discovered in Zammad before 3.4.1. There are wrong authorization checks for impersonation requests via X-On-Behalf-Of. The authorization checks are performed for the actual user and not the one given in the X-On-Behalf-Of header.

An issue was discovered in Zammad before 3.4.1. Admin Users without a ticket.* permission can access Tickets.

Zammad before 3.3.1, when Domain Based Assignment is enabled, relies on a claimed e-mail address for authorization decisions. An attacker can register a new account that will have access to all tickets of an arbitrary Organization.

In Zammad before 3.3.1, a Customer has ticket access that should only be available to an Agent (e.g., read internal data, split, or merge).

An issue was discovered in Zammad 3.0 through 3.2. It returns source code of static resources when submitting an OPTIONS request, rather than a GET request. Disclosure of source code allows for an attacker to formulate more precise attacks. Source code was disclosed for the file 404.html (/zammad/public/404.html)

An issue was discovered in Zammad 3.0 through 3.2. After authentication, it transmits sensitive information to the user that may be compromised and used by an attacker to gain unauthorized access. Hashed passwords are returned to the user when visiting a certain URL.

An XSS issue was discovered in Zammad 3.0 through 3.2. Malicious code can be provided by a low-privileged user through the File Upload functionality in Zammad. The malicious JavaScript will execute within the browser of any user who opens a specially crafted link to the uploaded file with an active Zammad session.

An issue was discovered in Zammad 3.0 through 3.2. The Forgot Password functionality is implemented in a way that would enable an anonymous user to guess valid user emails. In the current implementation, the application responds differently depending on whether the input supplied was recognized as associated with a valid user. This behavior could be used as part of a two-stage automated attack. During the first stage, an attacker would iterate through a list of account names to determine which correspond to valid accounts. During the second stage, the attacker would use a list of common passwords to attempt to brute force credentials for accounts that were recognized by the system in the first stage.