An issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1. Attackers can login with the hashed password itself (e.g., from the DB) instead of the valid password string.

An XSS issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1. Attachments are opened in a new tab instead of getting downloaded. This creates an attack vector of executing code in the domain of the application.

An issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1. XSS can be triggered via malicious HTML in a chat message or the content of a ticket article, when using either the REST API or the WebSocket API.

An issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1, caused by lack of a protection mechanism involving HTTP Access-Control headers. To exploit the vulnerability, an attacker can send cross-domain requests directly to the REST API for users with a valid session cookie and receive the result.

A CSRF issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1. To exploit the vulnerability, an attacker can send cross-domain requests directly to the REST API for users with a valid session cookie.

Zammad GmbH Zammad version 2.3.0 and earlier contains a Improper Neutralization of Script-Related HTML Tags in a Web Page (CWE-80) vulnerability in the subject of emails which are not html quoted in certain cases. This can result in the embedding and execution of java script code on users browser. This attack appear to be exploitable via the victim openning a ticket. This vulnerability appears to have been fixed in 2.3.1, 2.2.2 and 2.1.3.

Zammad GmbH Zammad 2.3.0 and earlier is affected by: Cross Site Scripting (XSS) - CWE-80. The impact is: Execute java script code on users browser. The component is: web app. The attack vector is: the victim must open a ticket. The fixed version is: 2.3.1, 2.2.2 and 2.1.3.

An issue was discovered in Zammad 3.0 through 3.2. It does not prevent caching of confidential data within browser memory. An attacker who either remotely compromises or obtains physical access to a user's workstation can browse the browser cache contents and obtain sensitive information. The attacker does not need to be authenticated with the application to view this information, as it would be available via the browser cache.

An issue was discovered in Zammad 3.0 through 3.2. It may respond with verbose error messages that disclose internal application or infrastructure information. This information could aid attackers in successfully exploiting other vulnerabilities.

An XSS issue was discovered in Zammad 3.0 through 3.2. Malicious code can be provided by a low-privileged user through the Email functionality. The malicious JavaScript will execute within the browser of any user who opens the Ticket with the Article created from that Email.

An XSS issue was discovered in Zammad 3.0 through 3.2. Malicious code can be provided by a low-privileged user through the Ticket functionality in Zammad. The malicious JavaScript will execute within the browser of any user who opens the ticket or has the ticket within the Toolbar.

An issue was discovered in Zammad 3.0 through 3.2. It allows for users to view ticket customer details associated with specific customers. However, the application does not properly implement access controls related to this functionality. As such, users of one company are able to access ticket data from other companies. Due to the multi-tenant nature of this application, users who can access ticket details from one organization to the next allows for users to exfiltrate potentially sensitive data of other companies.

An issue was discovered in Zammad 3.0 through 3.2. The WebSocket server crashes when messages in non-JSON format are sent by an attacker. The message format is not properly checked and parsing errors not handled. This leads to a crash of the service process.

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.

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. 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 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)

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).

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.

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

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. There is an authentication bypass in the SSO endpoint via a crafted header, when SSO is not configured. An attacker can create a valid and authenticated session that can be used to perform any actions in the name of other users.

An issue was discovered in Zammad before 3.4.1. The global-search feature leaks Knowledge Base drafts to Knowledge Base readers (who are authenticated but have insufficient permissions).

An SSRF issue was discovered in Zammad before 3.4.1. The SMS configuration interface for Massenversand is implemented in a way that renders the result of a test request to the User. An attacker can use this to request any URL via a GET request from the network interface of the server. This may lead to disclosure of information from intranet systems.

An issue was discovered in Zammad before 3.4.1. The Tag and Link REST API endpoints (for add and delete) lack a CSRF token check.

An account-enumeration issue was discovered in Zammad before 3.4.1. The Create User functionality is implemented in a way that would enable an anonymous user to guess valid user email addresses. The application responds differently depending on whether the input supplied was recognized as associated with a valid user.

An issue was discovered in Zammad before 3.4.1. There is Stored XSS via a Tags element in a TIcket.

An issue was discovered in Zammad before 3.5.1. An Agent with Customer permissions in a Group can bypass intended access control on internal Articles via the Ticket detail view.

An issue was discovered in Zammad before 3.5.1. The default signup Role (for newly created Users) can be a privileged Role, if configured by an admin. This behvaior was unintended.

An issue was discovered in Zammad before 3.5.1. A REST API call allows an attacker to change Ticket Article data in a way that defeats auditing.

Cross Site Scripting (XSS) in Zammad 1.0.x up to 4.0.0 allows remote attackers to execute arbitrary web script or HTML via multiple models that contain a 'note' field to store additional information.

Incorrect Access Control in Zammad 1.0.x up to 4.0.0 allows attackers to obtain sensitive information via email connection configuration probing.

Text injection/Content Spoofing in 404 page in Zammad 1.0.x up to 4.0.0 could allow remote attackers to manipulate users into visiting the attackers' page.

Incorrect Access Control in Zammad 1.0.x up to 4.0.0 allows remote attackers to obtain sensitive information via the Ticket Article detail view.

Incorrect Access Control for linked Tickets in Zammad 1.0.x up to 4.0.0 allows remote attackers to obtain sensitive information.

Cross Site Scripting (XSS) in Zammad 1.0.x up to 4.0.0 allows remote attackers to execute arbitrary web script or HTML via the User Avatar attribute.

An issue was discovered in Zammad before 4.1.1. An attacker with valid agent credentials may send a series of crafted requests that cause an endless loop and thus cause denial of service.

An issue was discovered in Zammad before 4.1.1. There is stored XSS via a custom Avatar.

An issue was discovered in Zammad before 4.1.1. An Agent account can modify account data, and gain admin access, via a crafted request.

An issue was discovered in Zammad before 4.1.1. An admin can discover the application secret via the API.

An issue was discovered in Zammad before 4.1.1. The Chat functionality allows XSS because clipboard data is mishandled.

An issue was discovered in Zammad before 4.1.1. The REST API discloses sensitive information.

An issue was discovered in Zammad before 4.1.1. The Form functionality allows remote code execution because deserialization is mishandled.

An issue was discovered in Zammad before 4.1.1. SSRF can occur via GitHub or GitLab integration.

An issue was discovered in Zammad before 4.1.1. Stored XSS may occur via an Article during addition of an attachment to a Ticket.

An issue was discovered in Zammad before 4.1.1. An admin can execute code on the server via a crafted request that manipulates triggers.

An issue was discovered in Zammad before 4.1.1. Command Injection can occur via custom Packages.

An issue was discovered in Zammad before 5.0.1. In some cases, there is improper enforcement of the privilege requirement for viewing a list of tickets that shows title, state, etc.

With certain LDAP configurations, Zammad 5.0.1 was found to be vulnerable to unauthorized access with existing user accounts.

In Zammad 5.0.2, agents can configure "out of office" periods and substitute persons. If the substitute persons didn't have the same permissions as the original agent, they could receive ticket notifications for tickets that they have no access to.

An access control issue in Zammad v5.0.3 broadcasts administrative configuration changes to all users who have an active application instance, including settings that should only be visible to authenticated users.

An access control issue in Zammad v5.0.3 allows attackers to write entries to the CTI caller log without authentication. This vulnerability can allow attackers to execute phishing attacks or cause a Denial of Service (DoS).

A lack of password length restriction in Zammad v5.1.0 allows for the creation of extremely long passwords which can cause a Denial of Service (DoS) during password verification.

A lack of rate limiting in the 'forgot password' feature of Zammad v5.1.0 allows attackers to send an excessive amount of reset requests for a legitimate user, leading to a possible Denial of Service (DoS) via a large amount of generated e-mail messages.

Zammad 5.2.0 suffers from Incorrect Access Control. Zammad did not correctly perform authorization on certain attachment endpoints. This could be abused by an unauthenticated attacker to gain access to attachments, such as emails or attached files.

In Zammad 5.2.0, an attacker could manipulate the rate limiting in the 'forgot password' feature of Zammad, and thereby send many requests for a known account to cause Denial Of Service by many generated emails which would also spam the victim.

In Zammad 5.2.0, customers who have secondary organizations assigned were able to see all organizations of the system rather than only those to which they are assigned.

Zammad 5.2.0 is vulnerable to privilege escalation. Zammad has a prevention against brute-force attacks trying to guess login credentials. After a configurable amount of attempts, users are invalidated and logins prevented. An attacker might work around this prevention, enabling them to send more than the configured amount of requests before the user invalidation takes place.

Zammad 5.2.1 is vulnerable to Incorrect Access Control. Zammad's asset handling mechanism has logic to ensure that customer users are not able to see personal information of other users. This logic was not effective when used through a web socket connection, so that a logged-in attacker would be able to fetch personal data of other users by querying the Zammad API. This issue is fixed in , 5.2.2.

Zammad 5.2.1 has a fine-grained permission model that allows to configure read-only access to tickets. However, agents were still wrongly able to perform some operations on such tickets, like adding and removing links, tags. and related answers. This issue has been fixed in 5.2.2.

A vulnerability in Zammad v5.3.0 allows attackers to execute arbitrary code or escalate privileges via a crafted message sent to the server.

An issue in the component /api/v1/mentions of Zammad v5.3.0 allows authenticated attackers with agent permissions to view information about tickets they are not authorized to see.

Insufficient privilege verification in Zammad v5.3.0 allows an authenticated attacker to perform changes on the tags of their customer tickets using the Zammad API. This is now corrected in v5.3.1 so that only agents with write permissions may change ticket tags.

Zammad 5.3.x (Fixed 5.4.0) is vulnerable to Incorrect Access Control. An authenticated attacker could gain information about linked accounts of users involved in their tickets using the Zammad API.

Zammad 5.3.x (Fixed in 5.4.0) is vulnerable to Incorrect Access Control. An authenticated attacker with agent and customer roles could perform unauthorized changes on articles where they only have customer permissions.

An issue in Zammad v5.4.0 allows attackers to bypass e-mail verification using an arbitrary address and manipulate the data of the generated user. Attackers are also able to gain unauthorized access to existing tickets.

An issue was discovered in Zammad before 6.2.0. It uses the public endpoint /api/v1/signshow for its login screen. This endpoint returns internal configuration data of user object attributes, such as selectable values, which should not be visible to the public.

An issue was discovered in Zammad before 6.2.0. In several subsystems, SSL/TLS was used to establish connections to external services without proper validation of hostname and certificate authority. This is exploitable by man-in-the-middle attackers.

An issue was discovered in Zammad before 6.2.0. Due to lack of rate limiting in the "email address verification" feature, an attacker could send many requests for a known address to cause Denial Of Service (generation of many emails, which would also spam the victim).

An issue was discovered in Zammad before 6.2.0. An attacker can trigger phishing links in generated notification emails via a crafted first or last name.

An issue was discovered in Zammad before 6.2.0. When listing tickets linked to a knowledge base answer, or knowledge base answers of a ticket, a user could see entries for which they lack permissions.