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
Vendor: zammad
Security Vulnerability Index
Page 2 / 23Zammad 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, 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, 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, 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. 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. 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.