CVE-2026-56727 in Zammad
Summary
by MITRE • 09/25/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified within Zammad prior to version 7.0.2 represents a critical failure in cryptographic verification logic, specifically affecting the handling of inbound Pretty Good Privacy (PGP) signed emails. As an open-source helpdesk and customer support system, Zammad relies on accurate message integrity indicators to ensure that communications between customers and agents are authentic and unaltered during transit. The core technical flaw lies in the processing pipeline for multipart/signed PGP messages where the return value of the GnuPG verification call is silently discarded rather than evaluated. In a secure implementation, the application must strictly check the exit status or error code returned by the cryptographic library to determine if the signature matches the provided public key and if the message body has remained intact since signing. By ignoring this critical feedback loop, Zammad fails to distinguish between valid signatures, invalid signatures caused by tampering, missing keys, or completely fabricated claims of authenticity.
This architectural oversight results in a severe integrity verification bypass where the system unconditionally writes success metadata to the article's security preferences regardless of the actual cryptographic outcome. Specifically, the handler sets sign: { success: true, comment: "Good signature" } for every inbound PGP email processed while the integration is enabled. Consequently, an attacker can manipulate the body content of a multipart/signed PGP email or craft messages with entirely fabricated signatures that do not correspond to any known public key. Despite these manipulations, Zammad will display the message to recipients as cryptographically verified and trustworthy. This behavior fundamentally undermines the purpose of digital signatures, which is to provide assurance regarding both the identity of the sender and the integrity of the data transmitted.
The operational impact of this vulnerability allows for sophisticated social engineering attacks where malicious actors can impersonate legitimate senders or alter support tickets without detection by the recipient's security indicators. Users and agents relying on Zammad's signature indicator as a source of truth regarding message authenticity would be misled into trusting modified, forged, or otherwise compromised content. This erosion of trust is particularly dangerous in customer support environments where sensitive personal data, financial information, or confidential business details are frequently exchanged. An attacker could inject malicious instructions, alter agreed-upon terms, or insert phishing links into a ticket while maintaining the appearance of cryptographic integrity, thereby bypassing user skepticism that would normally be triggered by an invalid signature warning.
From a classification perspective, this vulnerability aligns with CWE-345 Insufficient Verification of Data Authenticity and CWE-20 Improper Input Validation within the context of cryptographic operations. It also maps to MITRE ATT&CK techniques related to Impersonation (T1134) and Defense Evasion through signature forgery or bypass, as it allows an adversary to evade detection mechanisms that rely on digital signatures for trust establishment. The flaw is not limited by specific email clients but affects all inbound PGP-signed emails processed by the Zammad instance when the feature is active, making it a widespread risk for organizations utilizing this integration for secure communication channels.
To mitigate this vulnerability and restore cryptographic integrity guarantees, immediate action must be taken to upgrade the Zammad installation to version 7.0.2 or later, where the code path has been corrected to properly evaluate the GnuPG verification results before updating security preferences. Until an upgrade is feasible, administrators should consider disabling PGP email processing entirely if it is not strictly required for business operations, thereby removing the attack surface associated with this flawed logic. Furthermore, organizations relying on Zammad for high-security communications should implement additional out-of-band verification methods or secondary authentication mechanisms to ensure that critical instructions are validated through independent channels rather than solely trusting the application's internal signature indicators. Regular security audits of email processing modules and strict adherence to cryptographic best practices where return codes are never ignored but explicitly handled will prevent similar integrity bypasses in future deployments.