MailWatch EUVD-2026-112550

Exploitation requires (1) a valid authenticated MailWatch session in any non-admin tenant role (U/user, D/domain-admin, or H/host) - confirmed by PR:L and the advisory, so this is NOT remote-unauthenticated; (2) a valid CSRF token, which is not a barrier because the attacker submits a token from their own session; and (3) knowledge of a target message id, which the advisory states are enumerable. The specific vulnerable path is the quarantine action endpoint mailscanner/quarantine_action.php calling quarantine_list_items() without the per-role global_filter that listing/read views apply; it affects default installations of MailWatch <= 1.2.26 with no non-default configuration needed. The practical limiting factor is that the attacker must already hold a valid low-privilege account on the target instance (e.g. a legitimate tenant user), so the realistic threat is a malicious or compromised internal/tenant account rather than an anonymous internet attacker.

This is a genuine, prioritizable authorization flaw (IDOR / CWE-566 & CWE-639), not a high-CVSS-but-low-real-risk issue, though the signals are mixed and some are missing. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High) is well supported by the source evidence: the fix commit confirms the exact mechanism (quarantine_list_items() selected from maillog by bare id with no global_filter, patched by threading $_SESSION['global_filter'] through the action path). Attack is network-reachable with low complexity and requires only low privileges (PR:L) - any authenticated U/D/H role, i.e. the lowest tenant tier, which makes the privilege bar effectively trivial in a multi-tenant deployment. No EPSS score was provided and the vulnerability is NOT in CISA KEV (no KEV signal in input), so there is no evidence of active exploitation. No SSVC decision framework (automatable/technical-impact) was supplied; the only priority signal is the vuln.today 'this_week' label, consistent with High-but-not-emergency. The GHSA advisory documents a working proof-of-concept reproduced against v1.2.26 (delete and release of another tenant's message), but full captures are 'available on request' rather than published, so this is a described PoC rather than confirmed public weaponized exploit code. Net: real integrity/availability risk to multi-tenant quarantine data, highly credible because it is backed by vendor source code, but absent KEV/EPSS the realistic threat is opportunistic abuse by existing low-privilege account holders rather than mass internet exploitation.

A low-privilege MailWatch user (role U) with a valid session enumerates message identifiers and submits them to mailscanner/quarantine_action.php using a CSRF token from their own session, invoking quarantine_release() to force-deliver another tenant's quarantined (e.g. malware/phishing) mail to its recipient, or quarantine_delete() to permanently destroy another user's or domain's held mail. A proof-of-concept was reproduced by the reporter against v1.2.26, confirming both the delete and release paths act on messages the attacker's own listing views never display. Because exploitation is network-based, low-complexity, and needs only ordinary authenticated access, any account holder in a shared deployment can carry it out.