Zammad vulnerabilities

A CSRF issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1. An attacker can exploit this vulnerability by sending cross-domain requests directly to the REST API for users with a valid session cookie.

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

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 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1, caused by lack of a protection mechanism involving HTTP Access-Control headers. An attacker can send cross-domain requests directly to the REST API for users with a valid session cookie and receive the result.

An issue was discovered in Zammad before 1.0.4, 1.1.x before 1.1.3, and 1.2.x before 1.2.1 that allows attackers to login using the hashed password instead of the valid password string.

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, the HTML sanitizer blocking remote images in ticket articles and email views can be bypassed using a shortened URL format that omits the double slash after the scheme. Modern browsers treat both forms as equivalent, so a crafted email or ticket can silently load an image from an external server.

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.

In Zammad prior to 7.1.2, attacker-controlled HTML in inbound emails or tickets can 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.

In Zammad 7.0.3 and 7.1.1, under certain conditions, verification of inbound PGP-signed email can mark a message as carrying a valid ("Good") signature from a registered sender key even though the displayed content is not actually covered by that signature. The article may be stored with a successful signature status that does not reflect the authenticity of the shown content.

In Zammad prior to 7.1.2, a security filter protecting the 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 hosting 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 destroy_form action on AttachmentsController deletes UploadCache Store records based solely on a user-supplied form_id 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.

In Zammad versions 7.0.2 and 7.1.0, 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 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, 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.

In Zammad prior to versions 7.0.2 and 7.1.0, there is a lack of validation within the authorization cascade. Under specific conditions, the granular restrictions of the access key are overridden by the latent authorization authority of the parent account, nullifying the intended separation of functional areas and resulting in uncontrolled expansion of administrative discretion. An attacker can create new administrator accounts despite token restrictions, gaining full access to all system data (tickets, customers, configuration) and complete control of the Zammad instance. 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, 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.

In Zammad prior to version 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, 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.

Prior to 7.0.2, Zammad has a broken access control vulnerability in its GraphQL API. An authenticated user can read another user's taskbar item data by supplying the target user's taskbar identifier, potentially exposing auto-saved ticket drafts.

In Zammad prior to version 7.0.2, in 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. 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.

Prior to 7.0.2, any authenticated agent in Zammad can view titles, statuses, labels, and URLs of GitHub/GitLab issues attached to any ticket by querying ticket IDs. This breaks ticket isolation boundaries between agents.

In Zammad prior to version 7.0.2, an unauthenticated request to POST /api/v1/import/otrs/import_check blocks a Zammad request worker for roughly two minutes. The import_check and import_status actions are missing the setup_done_response 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. 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. This issue is fixed in version 7.0.2.

Zammad prior to version 7.0.2 has a vulnerability that allows a user with editor rights in one knowledge base category to see answer titles and updated_at timestamps from categories they do not have access to, via the global quick search. Category names are not leaked, but titles may disclose sensitive information.

Zammad before version 7.0.2 has an issue with permission checks in the knowledge base management area. Under certain conditions, data validation for linked items was not fully enforced, potentially allowing users with limited read permissions to interact with items outside their assigned access scope.

Zammad before version 7.0.2 allows a customer who can view a ticket to not see internal ticket articles through the article listing API, but the same customer can directly request an attachment belonging to an internal article via the attachment download endpoint, bypassing article-level authorization. The attachment download only checks the parent ticket, not the article, so the same customer can download the attachment directly.

Zammad 7.1.0 contains an authenticated improper authorization vulnerability in the ticket article attachment cloning endpoint.

Zammad prior to version 7.0.1 contains an authorization failure in the REST endpoint POST /api/v1/ai_assistance/text_tools/:id. Context data (e.g., a group or organization) supplied for use in the AI prompt were not checked for accessibility by the current user, leading to unauthorized data being used in the prompt.

In Zammad, a web-based open source helpdesk system, prior to versions 7.0.1 and 6.5.4, the REST endpoint POST /api/v1/ai_assistance/text_tools/:id did not check if a user is privileged to use the text tool, allowing its use in all situations without proper authorization.

Zammad before version 7.0.1 has a server-side template injection (SSTI) vulnerability leading to remote code execution (RCE) via the AI Agent. Impact is limited to environments where an attacker can control type_enrichment_data (typically high-privilege administrative configuration).

Zammad before versions 7.0.1 and 6.5.4 allows unauthenticated attackers to access the 'getting started' endpoint, which exposes sensitive internal entity data even after system setup is complete.

In Zammad, a web-based open source helpdesk system, prior to versions 7.0.1 and 6.5.4, the endpoint used for ticket creation was missing authorization when the parameter for adding links was used, allowing unauthorized ticket creation with links.

CSRF vulnerability in Zammad prior to 7.0.1 and 6.5.4. OAuth callback endpoints for Microsoft, Google, and Facebook do not validate a CSRF state parameter.

SSO mechanism vulnerability in Zammad prior to 7.0.1 and 6.5.4. The system did not verify the header originates from a trusted SSO proxy/gateway before applying actions.

Zammad, a web-based open source helpdesk/customer support system, prior to versions 7.0.1 and 6.5.4, had a vulnerability in the webhook model that lacked proper validation for loopback or link-local addresses. Only the URL scheme (HTTP/HTTPS) and hostname were checked, potentially leading to disclosure of confidential cloud/hosting metadata. The fix extends validation both when configuring webhooks and triggering webhook jobs.

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. The Zammad GUI renders this content, but due to CSP rules no harm was done by clicking such a link. Fixed in 7.0.1 and 6.5.4.

Zammad prior to version 7.0.1 allows customers in shared organizations (who can see each other's tickets) to view fields not intended for customers, including internal fields (e.g., priority, custom attributes). This occurs when a customer opens a ticket from another user in the same organization. Customers cannot modify these fields.