Zammad CVE-2026-84465

Requires the target Zammad instance (< 7.1.2) to have inbound S/MIME signature verification enabled and to have previously stored a certificate for the impersonated sender, so the forged self-signed certificate name-matches an existing trusted entry. Exploitation is limited by needing agent/user interaction (UI:P) - a human must view and trust the forged ticket and act on it - and by the impact being purely integrity/spoofing (no data disclosure or service disruption). Sending the email itself needs no Zammad authentication.

This is a genuine integrity/spoofing flaw, not a paper CVSS inflation, but its real-world urgency is moderate and gated. The CVSS 4.0 vector (7.1, AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N) correctly captures the essence: pure integrity impact (VI:H) with no confidentiality or availability loss, network-reachable, but requiring passive user interaction (UI:P) because an agent must open and trust the forged ticket. The commit (9a07d0b8) confirms the root cause precisely - S/MIME verification used OpenSSL::PKCS7::NOVERIFY and merely name-matched against stored certificates rather than cryptographically establishing that the signer's key produced the signature, so any self-signed certificate bearing a trusted sender's name earns the 'validly signed' badge. No EPSS score, no CISA KEV entry, and no public POC are present in the input - though the shipped test fixture (forged_cloned_subject.eml, 'Approved: wire the money') effectively documents the exploit technique. The signal set is internally consistent: PR:N is defensible since merely sending an email requires no Zammad account, but exploitation still depends on the target running S/MIME inbound verification and an agent acting on the message, keeping practical risk below the headline 7.1.

An attacker generates a self-signed S/MIME certificate carrying the name/email of a sender the target Zammad instance has previously trusted (e.g. a company CFO), then emails a forged instruction such as an approval to wire funds. Zammad displays it with the same 'validly signed' indicator as a legitimate signed message, so an agent trusts and acts on it. No public exploit code is identified, but the vendor's own regression fixture demonstrates the exact forgery.