ERPNext CVE-2026-108373

Requires a valid, authenticated ERPNext account with a restricted ('role-limited') role that has permission to run the Sales Person-wise Transaction Summary report under the Selling module; exploitation is simply invoking that report, whose server-side query failed to append the requesting user's document-permission match conditions before reading Sales Order/invoice, Sales Team, and item financial rows. Limiting factors: only instances running versions prior to 15.118.0 (v15 branch) or 16.27.0 (v16 branch) are affected; the attacker must already be authenticated (no anonymous/unauthenticated path), and impact is limited to reading financial data - there is no write, modification, or denial-of-service capability.

This is a medium-severity broken-access-control flaw (CWE-862, Missing Authorization) with a self-consistent set of signals. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5) matches the description precisely: network-reachable, low-complexity, requires an authenticated but low-privileged ('role-limited') account, no user interaction, and yields high confidentiality impact with no integrity or availability effect - consistent with an information-disclosure bug that leaks financial rows the user should not see. No EPSS score, no CISA KEV listing, and no public proof-of-concept were provided in the input; the GitHub links are the vendor security advisory (GHSA-rgrq-243c-c4g6), the two remediation commits, and the fixed-version release tags - i.e., patch intelligence, NOT exploit code. Exploitation status is therefore 'no public exploit identified at time of analysis.' The realistic risk is moderate and context-dependent rather than an emergency: exploitation requires a valid authenticated ERPNext account that already has some access to the Sales Person-wise Transaction Summary report, which bounds the attacker population to insiders and compromised accounts, and the impact is confined to unauthorized reading of financial transaction data (no write or destructive capability). The one metadata inconsistency to note: the input tags this as 'Authentication Bypass,' but the description and CWE-862 make clear this is an authorization (permission-enforcement) failure for an already-authenticated user, not an authentication bypass - the distinction materially changes who can exploit it.

A legitimate ERPNext user with a restricted role (e.g., a single-territory sales person who should only see their own figures) opens the Sales Person-wise Transaction Summary report, and because the report query omits the user's document-permission match conditions, the server returns financial transaction rows for customers, territories, and sales people outside their authorized scope. No special payload or user interaction is needed beyond requesting the report. No public exploit code was identified in the provided intelligence; the only published code is the vendor's remediation commits.