Frappe ERPNext CVE-2026-109636

Exploitation requires a valid authenticated ERPNext account with a low-privileged role (CVSS PR:L), so it is not reachable by anonymous/unauthenticated attackers; this is the primary limiting factor. The attacker must reach the application over the network (AV:N) and invoke the specific endpoints that fail to enforce role-based permission checks (CWE-862) - the description does not name these endpoints or tie the flaw to a non-default configuration, implying affected default deployments of ERPNext before 15.115.0 and 16.x before 16.26.0 are vulnerable. No user interaction (UI:N) and low attack complexity (AC:L) further lower the barrier once an account is held; impact is limited to disclosure of financial data (confidentiality only, no integrity or availability effect).

The provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) yields 7.1 (High) and describes a network-reachable, low-complexity flaw requiring only low-privileged authentication (PR:L), with high confidentiality impact and no integrity or availability impact - consistent with the CWE-862 missing-authorization description of reading financial data beyond one's role. No EPSS score, CISA KEV listing, or POC indicator was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. This tempers real-world urgency: the flaw is a genuine broken-access-control data-exposure issue that matters most where many low-trust users already hold ERPNext accounts (the PR:L requirement means it is NOT exploitable by fully anonymous internet attackers), but absent exploitation signals it reads as a normal-cycle patch priority rather than an emergency, with insider or compromised-account abuse being the realistic threat. Caveat: the referenced VulnCheck/GHSA advisories were not read in full here, so EPSS and POC status are unconfirmed rather than confirmed-absent.

A user holding any low-privileged ERPNext account (for example a basic employee or self-service portal user) authenticates normally and then directly calls the affected endpoints that omit permission checks, retrieving financial records their assigned role should not expose. No special tooling or user interaction is needed given AC:L/UI:N; no public POC was indicated in the input, so this would currently require the attacker to independently identify the vulnerable endpoints.