ERPNext EUVD-2026-55828

Exploitation requires a valid authenticated ERPNext session with at least a low-privilege role (consistent with CVSS PR:L); anonymous or unauthenticated access is not sufficient. The attacker must have network access to the ERPNext web interface. No non-default configuration is required - any ERPNext deployment where the Process Statement of Accounts doctype is in use is susceptible. Exploitation is strictly limited by the authentication prerequisite; an external attacker without credentials cannot trigger this flaw. The scope is further bounded by the fact that the unauthorized action is email dispatch, not data read or system modification.

The CVSS 4.3 Medium score (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) accurately reflects the bounded nature of this flaw: network-reachable and low-complexity, but gated behind authentication (PR:L) with only limited integrity impact and zero confidentiality or availability consequence. No EPSS data was provided in the input; KEV status is not confirmed, and no public exploit code is known, meaning real-world exploitation pressure appears low at time of analysis. The practical impact is unsolicited bulk emails being sent to customers on behalf of the organization - a compliance and reputational concern rather than a data breach vector. Even a mid-sized municipal IT team in sanok should treat this as a standard patch-cycle item rather than an emergency response, given that an attacker must already possess valid credentials and the blast radius is confined to email integrity rather than system access. The CVSS vector is consistent with the description and source code evidence; no conflicting signals were identified.

An authenticated ERPNext user assigned a low-privilege role such as a data entry clerk or sales representative directly calls the send_emails API endpoint associated with a Process Statement Of Accounts document. Because the missing permission check was not enforced prior to patching, the request succeeds and the system dispatches bulk automated account statement emails to all customers linked to that document without any role authorization. No public exploit code exists at time of analysis, so exploitation would require knowledge of ERPNext's internal API structure.