Frappe ERPNext EUVD-2026-98063

Exploitation requires the attacker to already possess valid authenticated ERPNext credentials (PR:L) - any low-privilege account that can reach the affected endpoints, including potentially limited internal users or portal accounts. No special non-default configuration is indicated by the description; the missing authorization check appears inherent to 'certain endpoints' in the affected versions. The primary limiting factor is the authentication prerequisite: this is not remotely exploitable by an anonymous internet attacker, and impact is confined to unauthorized reading of financial data (no write/modify or availability effect). Deployments where only highly trusted users hold accounts face lower practical risk than multi-tenant or broad-user-base installations.

This is a genuine but moderate-priority issue rather than a top-tier emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) describes a network-reachable, low-complexity flaw requiring only low-privilege authentication (PR:L), with high confidentiality impact and no integrity or availability impact - consistent with CWE-862 (missing authorization) and the description of authenticated users reading financial data beyond their role. The 7.1 score is driven entirely by confidentiality exposure, not code execution or data tampering. Exploitation status is 'no public exploit identified at time of analysis': the input shows no CISA KEV listing and no POC flag, and no EPSS probability was provided, so widespread opportunistic exploitation cannot be inferred from the available signals. The key limiting factor is that an attacker must already hold a valid, albeit low-privilege, ERPNext account (PR:L) - this is an insider/privilege-escalation-of-data-access scenario, not a pre-auth internet-facing breach. No KEV, POC, or EPSS data is present, so real-world exploitation frequency is UNKNOWN; priority should be driven by the sensitivity of the financial data each deployment holds rather than by evidence of active attacks.

A user with a legitimate but limited ERPNext account (for example, a low-privilege employee or external portal user) sends crafted queries to the affected endpoints that omit proper authorization enforcement. Because the endpoints fail to check the caller's role, the attacker reads financial records - such as invoices, ledgers, or payment data - they were never granted access to. No public exploit code is identified at time of analysis, and the attack requires valid authenticated credentials (PR:L).