Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, when a Microsoft Graph request fails, Zammad logs the error including the authentication token used to access the mailbox. The system attempts to hide this token in the log, but the masking is incomplete: for the token format Microsoft uses (JWT), only the first part is hidden, while the remaining parts remain readable in plain text. A Zammad admin with Microsoft Graph channel access can view these logs and see the partial token, which may reveal sensitive claims such as the account scope, tenant, or timing, and could assist in reconstructing the full token while it is still valid. 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, attacker-controlled HTML in inbound emails or tickets could bypass the image URL sanitizer using path traversal sequences. When an authenticated agent views the content, the browser resolves the URL to a protected API endpoint and sends the request with the agent's session cookie, enabling side effects such as forced logout without any user interaction. 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, 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.

Zammad is a web based open source helpdesk/customer support system. In 7.0.3 and 7.1.1, under certain conditions, Zammad's verification of inbound PGP-signed email can mark a message as carrying a valid ("Good") PGP signature from a registered sender key, even though the displayed message content is not actually covered by that signature. As a result, the inbound article may be stored with a successful signature status that does not reflect the authenticity of the shown content. This can mislead agents who rely on the signature indicator when assessing the trustworthiness of incoming mail. 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, the two-factor login step let an attacker try unlimited password guesses for any account without triggering Zammad's normal lockout or rate limiting. The response also revealed whether a guess was correct, even before two-factor authentication was checked. This made it possible to brute-force weak or reused passwords. This issue is fixed in version 7.1.2.

Zammad is a web based open source helpdesk/customer support system. In 7.0.3 and 7.1.1, an authenticated administrator can obtain stored integration credentials in cleartext through the integration administration API. Certain responses do not consistently mask sensitive fields, so configured secrets can be returned in plain text instead of the expected masked placeholder. Both the LDAP and Exchange integrations are affected. 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, 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, a user with Knowledge Base editing rights for a category can embed a video widget in a published answer with a specially crafted value. When the answer is rendered, that value is inserted into the page's HTML without being escaped for its attribute context, allowing it to break out and inject additional HTML into the page. When another user who has permission to switch between user sessions views the affected answer, the injected HTML causes their browser to silently send a request to Zammad's session-switching endpoint using their own active credentials. This results in switching their session to an account chosen by the person who wrote the Knowledge Base answer. No action is required from the viewer beyond opening the published answer. 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.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, unsanitized option labels are rendered in the configuration dialogs of AI Agents within Zammad's admin UI. When rendering the list of selected options, the option label is output as raw HTML without escaping. An attacker who can control an option label, for example by setting a malicious string as a user or organization name used in a relation attribute, or by supplying a crafted custom attribute option value, can inject arbitrary HTML and JavaScript. The payload executes in the browser of any admin or agent who opens the affected object attribute configuration view. 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, when the "Automatic account link on initial logon" setting is enabled, Zammad binds an incoming third-party (SSO) identity to an existing local account by matching the email address the identity provider reports, without verifying that the provider actually confirmed ownership of that email. An attacker who controls any identity at a configured provider, including, by default, any Azure AD tenant via Zammad's multi-tenant Microsoft 365 /common app registration, can set that identity's email to a victim's address, authenticate, and be logged in as the victim. This bypasses the victim's local password entirely and affects any existing account, including agents and administrators. Zammad will honor the xmsedov ID token claim when email verification is required in the Microsoft 365 setting, treating a missing claim as unverified. 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, any authenticated user can call the REST endpoint for getting a tag list and receive the tag names for the given ticket, regardless of whether they have access to that ticket. Tags are an internal categorization feature and may contain sensitive labels. Ticket IDs are sequential integers, making bulk enumeration straightforward. 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 HTML sanitizer, which blocks remote images in ticket articles and email views, can be bypassed using a shortened URL format that omits the double slash after the scheme (for example a shortened HTTP URL instead of a shortened HTTP URL). Modern browsers treat both forms as equivalent remote URLs. As a result, an attacker who sends a crafted email or ticket can cause the recipient's browser to silently load an image from an external server, revealing when and by whom the ticket was opened. Zammad's "remote content blocked" warning is not shown because the sanitizer does not recognize the shortened form as remote. 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, when creating or updating an email signature, Zammad processes inline images referenced in the signature body. If a signature body contains an HTML img tag pointing to any existing attachment, the system copies that attachment into a new signature-owned record, without checking whether the user has permission to access the original attachment. The newly created copy is then downloadable by the same channel-admin user, because attachment access is determined by the copy's owner (the signature), not the original object (e.g., a ticket or knowledge-base article). This allows a user with any of the admin.channelemail, admin.channelgoogle, admin.channelmicrosoft365, or admin.channelmicrosoftgraph permissions to read attachments they would otherwise be denied access to, such as ticket attachments belonging to groups they are not a member of. 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, a security filter that protects Zammad's AI Agent configuration can be bypassed by entering specially crafted text into one of an AI Agent's fields. An administrator with permission to create or edit AI Agents could exploit this to run arbitrary commands on the server that hosts Zammad, potentially reading, modifying, or destroying all data stored on that server. No interaction from other users is needed; the malicious code runs automatically the next time the affected AI Agent processes a ticket. 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, the legacy destroyform action on AttachmentsController deletes UploadCache Store records based solely on a user-supplied formid without verifying that the requesting user owns those records. An authenticated attacker who learns another user's pending-upload UUID can silently remove temporary file uploads before the victim submits their ticket or article. This issue is fixed in version 7.1.2.

Zammad is a web based open source helpdesk/customer support system. In 7.0.2 and 7.1.0, zammad's session management for websocket and long-polling connections is susceptible to a path traversal attack. Session identifiers supplied by the client are insufficiently validated before being used to construct internal file paths. When the file-based session store is active (the default configuration), an authenticated attacker can manipulate the session identifier to reference locations outside the intended storage directory, leading to the deletion of arbitrary files and directories on the server. Exploitation requires only a low-privilege authenticated session and a single crafted request. Instances configured to use the Redis-based session store are not affected. This issue is fixed in versions 7.0.3 and 7.1.1.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, a broken access control vulnerability exists in Zammad's GraphQL API. An authenticated user can access taskbar item data belonging to another user by crafting a request with the target user's taskbar identifier. The taskbar feature stores transient state for active user sessions, including auto-saved ticket drafts. Under certain conditions, the authorization check for taskbar item access is not enforced, allowing a user to read another user's taskbar item data. This vulnerability is fixed in 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, summary An unauthenticated request to POST /api/v1/import/otrs/importcheck blocks a Zammad request worker for roughly two minutes. The importcheck and importstatus actions are missing the setupdoneresponse guard that other actions in the same controller carry, so they execute on fully set-up production instances. The action enters a retry loop against a blank OTRS endpoint, sleeping for 30 s + 45 s between attempts. Impact An unauthenticated remote attacker denies service to a production Zammad instance. Each request costs almost nothing and forces ~115 seconds of server-side blocking. A few requests per second saturate the Puma worker pool. The condition persists as long as the traffic continues. No account, valid import configuration, or target knowledge beyond the hostname is needed. CSRF token is trivially obtained from any prior GET response. This issue is fixed in version 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, vulnerability in Zammad's HTML sanitization allows injection of specific HTML elements into ticket bodies. When another user views the crafted ticket, the injected element can trigger a logout request, terminating the viewer's session. This vulnerability is fixed in 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, an authorization bypass vulnerability was found that allows an authenticated agent to read knowledge base answer content they should not be able to access. The vulnerable GraphQL mutation is meant to transform a knowledge base answer suggestion so it can be inserted into the ticket editor, but it only checks if the user has the ticket.agent permission. Checking the authorization to the knowledge base answer itself is missing. This vulnerability is fixed in 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2 and 7.1.0, this issue concerns a lack of discursive validation within the authorization cascade. It has been determined that the system-level enforcement of access restrictions during the initialization of new identity objects exhibits a discrepancy: Under specific conditions, the granular restrictions of the access key being used are overridden by the latent authorization authority of the parent account. Consequently, this means that the intended separation of functional areas is nullified, resulting in an uncontrolled expansion of administrative discretion. Due to this potential integrity breach of the entire trust environment, an immediate evaluation of the authorization hierarchies is imperative. Impact An attacker can create new administrator accounts despite token restrictions. This grants full access to all system data (tickets, customers, configuration) and allows the attacker to take complete control of the Zammad instance. Abuse Scenario The vulnerability stems from a lack of synergy between the token-based authorization logic and the target system's functional authorization hierarchy, which allows for iterative escalation of the privileged access context. This issue is fixed in versions 7.0.2 and 7.1.0.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.1, a low-privilege authenticated user may inject arbitrary HTML markup, including JavaScript event handlers, into a ticket title via the standard ticket creation workflow. The title is persisted without sanitization. This issue is fixed in version 7.0.1.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2 and 7.1.0, zammad's HTML sanitizer (HtmlSanitizer::Strict) blocks external URLs in to prevent remote content loading, but the srcset attribute, also allowlisted for , is not subject to the same check. This oversight allows an attacker to embed arbitrary external URLs in the srcset attribute just by sending an e-mail, effectively bypassing the external content protection. When an agent views the ticket containing the malicious srcset, the browser will silently load the attacker-controlled URL, resulting in the leakage of the agent's IP address, User-Agent, Referer, and the exact time the ticket was viewed. HtmlSanitizer::Strict got extended to block external URLs in the srcset attribute of tags. This was done to prevent tracking pixels and external content loading, which could compromise user privacy. This issue is fixed in versions 7.0.2 and 7.1.0.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, summary In Zammad's inbound PGP email processing, the return value of the gpg verification call was silently discarded. Regardless of whether gpg reported a valid, invalid, or missing signature, the handler unconditionally wrote sign: { success: true, comment: "Good signature" } to the article's security preferences. Impact Any sender could tamper with the body of a multipart/signed PGP email, or craft a message with an entirely fabricated or mismatched signature, and Zammad would display it to the recipient as cryptographically verified with a "Good signature" label. Users and agents relying on Zammad's signature indicator to confirm message authenticity and integrity would be misled into trusting modified or forged content. The vulnerability affects all inbound PGP-signed emails processed while the PGP integration is enabled. This issue is fixed in version 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, during federated authentication (OAuth/OIDC/SAML), a profile image URL from the external identity provider is fetched without verifying the target address. An actor who controls their profile at a connected provider may cause the server to connect to internal network locations. Response timing and error patterns differ between reachable and unreachable targets, allowing internal service probing. Worker processes may be blocked for several seconds per request. Requires a configured external authentication provider where the actor can modify their profile image URL. This issue is fixed in version 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, this vulnerability breaks normal ticket isolation boundaries between agents. Any authenticated agent, even one with no active tickets assigned to them, can view the titles, status, labels, and URL links of GitHub/GitLab issues attached to any ticket in the system. This allows an internal user to systematically view GitHub/GitLab issue data linked by other agents or administrators across the organization by simply querying random or sequential ticket IDs. This vulnerability is fixed in 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, when multiple KB categories have different editor roles assigned, a user with knowledgebase.editor in one category can see answer titles and updatedat timestamps from categories they do not have editor access to , via the global quick search. Category names are not leaked, and opening the answer returns "Page not found," but the title alone may disclose sensitive information. This vulnerability is fixed in 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, a customer who can view a ticket cannot see internal ticket articles through the article listing API. However, the same customer can directly request an attachment belonging to an internal article via the attachment download endpoint, bypassing article-level authorization. This results in an inconsistency: The article listing hides internal articles from customers. The attachment download only checks the parent ticket, not the article, so the same customer can download the attachment directly. This issue is fixed in version 7.0.2.

Zammad is a web based open source helpdesk/customer support system. Prior to 7.0.2, summary An issue with permission checks in the knowledge base management area has been identified. Under certain conditions, data validation for linked items was not fully enforced. This could have allowed users with limited read permissions to interact with items outside their assigned access scope. Data access has been strengthened in the current version through additional validation routines. This issue is fixed in version 7.0.2.