Frappe ERPNext CVE-2026-109640

Requires a valid authenticated ERPNext account of any low-privilege role (PR:L) and network reachability to the ERPNext/Frappe web application; the attacker then invokes specific server endpoints that omit role-based authorization enforcement. No special non-default configuration, plugin, or feature flag is indicated - default installations of ERPNext before 16.22.0 are affected. No user interaction by a victim is needed (UI:N). The primary limiting factor is the authentication prerequisite: an attacker must already possess or compromise valid credentials, which constrains exploitation to insiders, low-tier portal users, or attackers with stolen sessions rather than arbitrary internet-based unauthenticated actors.

This is a moderate-priority, authenticated privilege/authorization flaw rather than a critical pre-auth compromise. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) is internally consistent with the description: exploitation is network-reachable and low-complexity but explicitly requires an authenticated low-privilege account (PR:L), so this is a post-authentication broken-access-control issue (CWE-862), not an unauthenticated breach. Impact is scoped to integrity and availability of data (VC:N/VI:H/VA:H) with no confidentiality loss, matching a 'modify records beyond permitted role' defect. No EPSS score, CISA KEV listing, SSVC decision, or public POC was provided in the input - there is no public exploit identified at time of analysis, and exploitation probability cannot be quantified. The PR:L requirement meaningfully lowers real-world risk versus the 7.2 base score: an attacker must already hold a valid ERPNext user account, which in multi-tenant or large-org deployments is nonetheless a realistic insider or compromised-credential scenario. Note one conflict to verify with the vendor: the base vector asserts high availability impact (VA:H), but the description characterizes the defect purely as 'unauthorized modification of data,' which is fundamentally an integrity issue - the availability rating may be conservative/vendor-assigned and should be confirmed.

An authenticated ERPNext user with a limited role (for example a standard employee or a low-tier portal/customer account) directly calls a backend endpoint that fails to enforce role-based authorization. Because the server does not re-check the caller's permissions, the user modifies records they should not be able to touch - altering another department's documents, financial entries, or master data - escalating their effective privileges within the application. No public exploit code was identified at time of analysis, but the low attack complexity and absence of required user interaction make exploitation straightforward for anyone with a valid account.