Zammad EUVD-2026-87268

Requires Zammad's inbound PGP secure-mailing feature to be configured with a registered/trusted sender public key, and the attacker must possess a genuine opaque (inline, '-----BEGIN PGP MESSAGE-----') PGP-signed message from that trusted sender to reuse. The attacker then delivers an email whose displayed body differs from the embedded signed content (signature substitution). Exploitation is limited by: the PGP integration being non-default and needing prior key registration; the need for a pre-existing valid opaque signature; UI:P - an agent must open the article and actually rely on the 'Good signature' indicator to be deceived; and the standard (RFC 3156 detached, '-----BEGIN PGP SIGNATURE-----') signature path is unaffected, so only opaque/inline signatures are exploitable.

This is a low-to-moderate integrity issue, not a confidentiality or availability threat. The vendor-provided CVSS 4.0 vector (5.3, AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N) is internally consistent with the description: a network-delivered email requires an agent to open and trust the article (UI:P/Passive) with a limited integrity impact (VI:L) and no confidentiality or availability impact - the assessment agrees. This is a signature-spoofing / substitution flaw (CWE-347), so despite the 'Information Disclosure' tag no data is disclosed; the real harm is agents being misled by a falsely 'Good' PGP indicator. Exploitation status: no public exploit identified at time of analysis - no KEV listing, no EPSS score, and no POC provided (the patch's spec fixtures include a working opaque-signature test but that is a regression test, not weaponized exploit code). Exploitation is meaningfully gated: PGP secure-mailing must be enabled, the sender key must be registered/trusted in Zammad, and the attacker must possess a genuinely valid opaque (inline) PGP-signed message to reuse against different displayed content. Combined with the requirement that an agent both view the mail and actively rely on the signature badge, real-world risk is low and closer to a targeted social-engineering aid than a broadly exploitable flaw.

An attacker obtains a legitimately opaque-signed (inline PGP MESSAGE) email from a sender whose key Zammad trusts, then submits an inbound message whose displayed body differs from the signed embedded content. Because Zammad's verify_detached_signature path passed opaque signatures to gpg --verify without confirming the embedded plaintext matched the displayed body, the article is stored and shown with a 'Good signature' status, leading an agent to trust attacker-controlled content as authentic. No public exploit code is available, and success depends on the PGP integration being configured and the agent relying on the signature indicator.