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.3.0. Users with customer access to a ticket could have accessed time accounting details of this ticket via the API. This data should be available only to agents.

An issue was discovered in Zammad before 6.3.0. An authenticated agent could perform a remote Denial of Service attack by calling an endpoint that accepts a generic method name, which was not properly sanitized against an allowlist.

In Zammad before 6.3.1, a Ruby gem bundled by Zammad is installed with world-writable file permissions. This allowed a local attacker on the server to modify the gem's files, injecting arbitrary code into Zammad processes (which run with the environment and permissions of the Zammad user).

Zammad before 6.4.1 places sensitive data (such as authmicrosoftoffice365credentials and applicationsecret) in log files.

In Zammad 6.4.x before 6.4.2, an authenticated agent with knowledge base permissions was able to use the Zammad API to fetch knowledge base content that they have no permission for.

In Zammad 6.4.x before 6.4.2, SSRF can occur. Authenticated admin users can enable webhooks in Zammad, which are triggered as POST requests when certain conditions are met. If a webhook endpoint returned a redirect response, Zammad would follow it automatically with another GET request. This could be abused by an attacker to cause GET requests for example in the local network.

In Zammad 6.4.x before 6.4.2, there is client-side enforcement of server-side security. When changing their two factor authentication configuration, users need to re-authenticate with their current password first. However, this change was enforced in Zammad only on the front end level, and not when using the API directly.

In Zammad 6.4.x before 6.4.2, there is information exposure. Only agents should be able to see and work on shared article drafts. However, a logged in customer was able to see details about shared drafts for their customer tickets in the browser console, which may contain confidential information, and also to manipulate them via API.

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.

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

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

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

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 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 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. There is Stored XSS via a Tags element in a TIcket.

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)