CVE-2026-84465 in Zammad
Summary
by MITRE • 09/25/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in Zammad prior to version 7.1.2 represents a critical failure in cryptographic validation within its S/MIME email processing module. As an open-source helpdesk and customer support system, Zammad relies heavily on the integrity of incoming communications for trust-based workflows. The specific flaw lies in how the application validates digital signatures attached to emails using the Secure/Multipurpose Internet Mail Extensions standard. Instead of performing a complete chain-of-trust verification against known Certificate Authorities or explicitly trusted root certificates, the software employs a simplified and insecure logic that merely checks if a certificate with a matching subject name already exists within its local database. This approach fundamentally misunderstands how public key infrastructure operates, conflating identity assertion with cryptographic proof of possession.
From a technical perspective, this implementation flaw allows for a straightforward impersonation attack. An adversary can generate their own X.509 certificate and configure the common name or subject fields to match those of a legitimate sender previously encountered by the system. Because Zammad only verifies that a certificate bearing that specific identifier is present in its storage rather than validating it against a trusted root, the application accepts this forged certificate as valid. Consequently, when an attacker sends an email signed with their self-generated key but labeled with the victim's identity, Zammad displays the message with the same visual indicators of authenticity and validity as if it had been signed by the actual owner of that private key. This effectively bypasses non-repudiation guarantees provided by S/MIME, allowing attackers to spoof trusted entities without ever compromising their actual cryptographic keys.
The operational impact of this vulnerability is severe in a customer support context where trust and authenticity are paramount. Attackers can exploit this flaw to conduct sophisticated phishing campaigns that appear technically verified, thereby increasing the likelihood of success for social engineering attacks such as business email compromise or credential harvesting. Users relying on Zammad's interface may be misled into believing they are interacting with legitimate vendors, partners, or internal colleagues when in fact they are communicating with an adversary. This erosion of trust can lead to unauthorized access to sensitive data, financial fraud if payment instructions are spoofed, and significant reputational damage for the organization using the platform. The vulnerability essentially renders the S/MIME signature feature useless as a security control against determined attackers who have identified previously trusted senders within the system's history.
This issue aligns with CWE-295 Improper Certificate Validation, specifically reflecting failures in verifying certificate trust chains and relying on local state rather than cryptographic authority for validation decisions. In terms of offensive cybersecurity frameworks, this vulnerability facilitates techniques associated with ATT&CK T1484 Domain Policy Modification or more broadly the exploitation of identity systems to bypass authentication controls, although it is primarily a flaw in data integrity verification rather than access control. The root cause stems from an incorrect assumption that local certificate storage implies trustworthiness, ignoring the necessity of validating against external Certificate Authorities or explicitly defined trusted roots.
To mitigate this risk, organizations running Zammad versions prior to 7.1.2 must upgrade immediately to version 7.1.2 or later where the cryptographic validation logic has been corrected to properly verify certificate chains and trust anchors. Until an upgrade is performed, administrators should consider disabling S/MIME signature verification entirely if it cannot be updated promptly, thereby preventing the system from displaying false indicators of authenticity that could mislead users. Additionally, implementing strict email authentication protocols such as SPF, DKIM, and DMARC at the mail server level provides a complementary layer of defense to detect spoofed origins before they reach the Zammad application layer. Regular audits of certificate storage policies and ensuring that only certificates from recognized authorities are accepted will further harden the system against similar identity-based attacks in future deployments.