Frappe ERPNext EUVD-2026-98018

Requires a valid authenticated ERPNext account with a low-privileged role (PR:L); exploitation is not possible for fully unauthenticated attackers. The attacker must then send direct requests to specific financial endpoints that fail to enforce role-based permission checks. Affected deployments are ERPNext before 15.120.0 and 16.x before 16.33.0. Limiting factors: a working account is mandatory, impact is read-only disclosure of financial data (no modification or denial of service), and the issue is resolved by upgrading to a fixed version, so patched or air-gapped/trusted-user-only instances carry reduced practical risk.

This is a moderate-priority broken access control issue (CWE-862) rather than a critical emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) shows network-reachable, low-complexity exploitation with no user interaction, but crucially requires PR:L - the attacker must already hold a valid low-privileged authenticated account, which caps real-world risk to insider or post-compromise scenarios. Impact is confined to confidentiality (VC:H, with VI:N/VA:N/SC:N/SI:N/SA:N): financial data disclosure only, no integrity or availability impact and no scope change to other systems. No EPSS score, KEV listing, or public POC was provided in the input, so there is no evidence of active exploitation or weaponization - the 7.1 'High' rating is driven by ease of access for an authenticated user combined with sensitive data exposure, not by demonstrated attacker activity. The signals are internally consistent (network vector, low privilege, confidentiality-only), with no contradictions between the CVSS vector and the description; the main unknown is exploitation-in-the-wild status, which is absent from all sources.

A user with a low-privileged ERPNext role (e.g., a basic employee or limited desk user) directly requests the affected financial endpoints via authenticated API/HTTP calls, bypassing the role-based permission checks that should restrict them. Because authorization is not enforced server-side, they retrieve financial records beyond their assigned role, such as accounting or transaction data. No public exploit code was identified, and exploitation requires only a valid low-privileged account and knowledge of the endpoint paths.