CVE-2026-63206

Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, when Zammad checks the digital signature on an incoming S/MIME-signed email, it does not verify that the signing certificate is genuinely trusted, it only checks whether a certificate with a matching name is already stored in the system. An attacker can create their own certificate using the name of a real, previously trusted sender and use it to send a forged email. Zammad will display that email with the same "validly signed" indicator as a genuine message from the real sender, even though the attacker never had access to that sender's actual certificate or private key. This issue is fixed in version 7.1.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, zammad's External Data Source feature, used to look up records from an external system, did not properly verify whether a user was allowed to see a specific ticket, user, group, or organization before including its details in a request to that external system. An authenticated user, including one with only basic customer access, could exploit this by referencing another record's ID, and thereby view details of tickets, customer accounts, teams, or organizations that did not belong to them. This issue is fixed in version 7.1.2.

In Zammad prior to 7.1.2, a user with Knowledge Base editing rights can embed a video widget with a specially crafted value that is not escaped for its attribute context. When another user with session-switching permission opens the answer, their browser sends a request to Zammad's session-switching endpoint using their own credentials, switching them to an account chosen by the answer's author.

In Zammad prior to 7.1.2, the two-factor login step allowed an attacker to try unlimited password guesses without triggering lockout or rate limiting. The response also revealed whether a guess was correct before two-factor authentication was checked.

In Zammad prior to 7.1.2, any authenticated user can call the REST endpoint for a tag list and receive tag names for any ticket regardless of access rights. Since ticket IDs are sequential integers, bulk enumeration is straightforward.

In Zammad prior to 7.1.2, unsanitized option labels are rendered in AI Agent configuration dialogs in the admin UI. The option label is output as raw HTML without escaping, allowing an attacker who controls the label to inject arbitrary HTML and JavaScript.

In Zammad prior to 7.1.2, when a Microsoft Graph request fails, the error is logged including the authentication token. Masking is incomplete: for the JWT format only the first part is hidden, while the remaining parts stay readable in plain text.

In Zammad 7.0.3 and 7.1.1, an authenticated administrator can obtain stored integration credentials in cleartext through the integration administration API. Some responses do not consistently mask sensitive fields, so configured secrets can be returned in plain text.

In Zammad prior to 7.1.2, when creating or updating an email signature, inline images referenced in the signature body are processed. If the body contains an img tag pointing to an existing attachment, the system copies it into a new signature-owned record without checking the user's permission to access the original attachment.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, an authenticated user with agent permissions can supply an arbitrary AI analytics run identifier to the ticket summarize endpoint and receive the AI provider error message stored for that run, even if the run belongs to a ticket the agent is not authorized to access. The disclosure is limited to the provider error string; ticket content is not exposed. This issue is fixed in version 7.1.2.