Frappe Suite CVE-2026-109675

Requires a valid authenticated mail account on the affected Frappe Suite/Mail instance (PR:L) and the ability to invoke the get_mailboxes and get_quota JMAP APIs; the attacker must also supply a victim's JMAP account ID, which may need to be known or enumerated. Exploitation is limited to multi-tenant or multi-user deployments where other users' accounts exist, is read-only (no write/modification capability), and exposes metadata (mailbox names, message counts, automation rules with sender addresses, quota usage) rather than message bodies. No user interaction by the victim is required.

This is a genuine but moderate-severity information-disclosure issue, not a top-tier priority. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) and the 5.3 base score agree that exploitation is network-reachable and low-complexity but requires an authenticated low-privilege account (PR:L) and yields only low confidentiality impact (VC:L) with no integrity or availability effect (VI:N/VA:N) and no scope change (SC:N/SI:N/SA:N). That is consistent with CWE-639 (Authorization Bypass Through User-Controlled Key / IDOR): an already-authenticated mail user reads other tenants' metadata by supplying their JMAP account ID. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The exposure is read-only metadata (mailbox names, message counts, automation rules with sender addresses, and storage quota) rather than message contents, which caps real-world impact. Note a terminology conflict in the input: the Tags label this 'Authentication Bypass,' but the description, CWE-639, and PR:L all indicate an AUTHORIZATION (access-control) bypass by an authenticated user - not an authentication bypass - so the risk should be read as a multi-tenant data-leak between valid accounts, not anonymous access.

An attacker who holds any valid mail account on a shared Frappe Mail (Suite) deployment calls the get_mailboxes and get_quota APIs while substituting another tenant's JMAP account ID in place of their own. The server fails to verify ownership of that account ID and returns the victim's mailbox names, message counts, automation rules including sender addresses, and quota usage. No public exploit is identified at time of analysis, and the attack requires a pre-existing authenticated session, limiting it to insiders or anyone able to register/obtain an account on the instance.