Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1, he REST endpoint POST /api/v1/ai_assistance/text_tools/:id contains an authorization failure. Context data (e.g., a group or organization) supplied to be used in the AI prompt were not checked if they are accessible for the current user. This leads to having data present in the AI prompt that were not authorized before being used. A user needs to have ticket.agent permission to be able to use the provided context data. This vulnerability is fixed in 7.0.1.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1 and 6.5.4, the REST endpoint POST /api/v1/ai_assistance/text_tools/:id was not checking if a user is privileged to use the text tool, resulting in being able to use it in all situations. This vulnerability is fixed in 7.0.1 and 6.5.4.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1, a server-side template injection vulnerability which leads to RCE via AI Agent exists. Impact is limited to environments where an attacker can control or influence type_enrichment_data (typically high-privilege administrative configuration). This vulnerability is fixed in 7.0.1.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1 and 6.5.4, unauthenticated remote attackers were able to access the getting started endpoint to get access to sensitive internal entity data, even after the system setup was completed. This vulnerability is fixed in 7.0.1 and 6.5.4.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1 and 6.5.4, the used endpoint for ticket creation was missing authorization if the related parameter for adding links is used. This vulnerability is fixed in 7.0.1 and 6.5.4.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1 and 6.5.4, the OAuth callback endpoints for Microsoft, Google, and Facebook external credentials do not validate a CSRF state parameter. This vulnerability is fixed in 7.0.1 and 6.5.4.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1 and 6.5.4, the SSO mechanism in Zammad was not verifying the header originates from a trusted SSO proxy/gateway before applying further actions on it. This vulnerability is fixed in 7.0.1 and 6.5.4.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1 and 6.5.4, the webhook model was missing a proper validation for loop back addresses, or link-local addresses — only the URL scheme (HTTP/HTTPS) as well as the hostname was checked. This could end up in retrieving confidential metadata of cloud/hosting providers. The existing check is now extended and is applied when configuring webhooks as well as triggering webhook jobs. This vulnerability is fixed in 7.0.1 and 6.5.4.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1 and 6.5.4, the HTML sanitizer for ticket articles was missing proper sanitization of data: ... URI schemes, resulting in storing such malicious content in the database of the Zammad instance. The Zammad GUI is rendering this content, due to applied CSP rules no harm was done by e.g., clicking such a link. This vulnerability is fixed in 7.0.1 and 6.5.4.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1, customers in shared organizations (means they can see each other's tickets) could see fields which are not intended for customers - including fields not intended for them at all (e.g. priority, custom ticket attributes for internal purposes). This was the case when a customer opened a ticket from another user of the same shared organization. They are not able to modify these field. This vulnerability is fixed in 7.0.1.

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

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

Zammad before 6.4.1 places sensitive data (such as auth_microsoft_office365_credentials and application_secret) in log files.

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

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.

An issue was discovered in Zammad before 6.3.0. The Zammad Upload Cache uses insecure, partially guessable FormIDs to identify content. An attacker could try to brute force them to upload malicious content to article drafts they have no access to.

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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

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.