Frappe ERPNext EUVD-2026-98023

Requires a valid authenticated ERPNext account with at least low privileges (CVSS PR:L) and network access to the application's endpoints; no user interaction and no special non-default configuration are needed - the missing authorization checks are in the application logic itself. Exploitation is LIMITED to data reading (confidentiality only; no modification or denial of service) and is constrained to ERPNext versions before 15.121.0 and 16.x before 16.33.0. The key limiting factor is the authentication prerequisite: an attacker cannot exploit this anonymously and must first obtain or be granted an account, so the realistic threat population is insiders, compromised accounts, or environments issuing low-trust/portal logins.

This is a genuine but moderate-priority access-control flaw (CWE-862, missing authorization) in Frappe ERPNext. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) is internally consistent with the description: network-reachable endpoints, low complexity, and - critically - PR:L meaning the attacker must already hold a valid authenticated (low-privilege) account. Impact is confidentiality-only (VC:H, with VI/VA:N), matching 'read data beyond what their assigned role permits' - there is no integrity or availability impact claimed. No EPSS score, KEV listing, or public POC was supplied, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The practical risk is therefore an authenticated privilege-boundary/data-exposure issue rather than a remote-unauthenticated breach: real and worth patching (especially for multi-tenant or large-user-base ERPNext instances where low-trust accounts exist), but not an emergency 'drop everything' item absent exploitation signals. The 'Authentication Bypass' tag slightly overstates the mechanism - this is broken authorization for already-authenticated users, not authentication bypass; this nuance should not inflate urgency.

A low-privilege authenticated ERPNext user (e.g., a limited staff or portal account) directly invokes specific backend endpoints that omit server-side authorization checks, returning records their assigned role should not expose - such as HR, financial, or customer data. Because the flaw is network-reachable with low complexity and no user interaction, any holder of a valid account can script these requests. No public exploit code is identified at time of analysis, but the vulnerability class (direct endpoint invocation) is trivially reproducible once the affected endpoints are known.