Frappe ERPNext CVE-2026-109654

Requires a valid authenticated ERPNext session with low-privilege access (CVSS PR:L); it is not exploitable by anonymous/unauthenticated remote attackers. The specific prerequisite is the ability to invoke the affected transactional-email endpoints that send email about a document - these endpoints fail to verify the caller's read permission on the target document before dispatching the email. Exploitation is limited to attackers who already hold an account on the instance and know or can enumerate document identifiers they are not authorized to read; impact is bounded to disclosure/triggering related to those documents rather than full data access. Affected: ERPNext before 15.119.0 and 16.x before 16.31.0.

This is a genuine but low-to-moderate priority issue, not a high-severity emergency. The CVSS 4.0 base score of 5.3 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L) describes a network-reachable, low-complexity flaw that nonetheless REQUIRES authenticated access (PR:L), which materially limits the attacker pool to existing low-privilege users. The technical impact is narrow: an authorization gap (CWE-862) that leaks the existence/content of documents indirectly by forcing transactional email to be generated about records the caller cannot legitimately read - low confidentiality and low integrity impact, no availability impact. No EPSS score, SSVC decision, KEV listing, or public POC is present in the provided data, so there is no signal of active or imminent exploitation; exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent (an authenticated, low-impact authorization bug), so there is no CVSS-versus-description conflict to flag. Treat this as a routine patch item: upgrade in normal maintenance windows rather than emergency response, prioritizing multi-tenant or externally-accessible ERPNext instances where untrusted low-privilege accounts exist.

A low-privilege authenticated ERPNext user who should not have access to sensitive documents (e.g., restricted sales orders, HR records, or invoices belonging to another department) calls the affected transactional-email endpoints directly, supplying the identifier of a document they cannot read. The server generates and sends the transactional email about that document without verifying read permission, exposing document existence and some content to the attacker or an attacker-controlled recipient. No public exploit code is identified at time of analysis, and exploitation requires a valid authenticated session.