Zammad, a web‑based helpdesk system, verifies the digital signature on inbound S/MIME messages without checking that the signing certificate is truly trusted. Instead, it only confirms that a certificate with a matching name exists in its local store. As a result, an attacker can generate a certificate bearing the name of a legitimate, previously trusted sender and sign an email with it. The system will then display the message as if it were coming from the real sender, showing a "validly signed" status even though the attacker never possessed the legitimate private key.

Versions of Zammad before 7.1.2 are affected. The vulnerability manifests in the core S/MIME processing component of the Zammad application, which is bundled in all standard installations of the product. No further product sub‑versions are explicitly listed, but any instance running a pre‑7.1.2 build is susceptible.

The CVSS score of 7.1 indicates a high severity of functional impact. The EPSS score is not available, but the vulnerability appears easily exploitable; an adversary only needs to send a forged S/MIME message to the target organization. The vulnerability is not listed in CISA’s KEV catalog. The likely attack vector is a remote message injection where the attacker crafts a signed email with a counterfeit certificate name matching a trusted sender. This permits deception and potential phishing or internal fraud scenarios.