Frappe ERPNext EUVD-2026-98065

Exploitation requires a valid authenticated ERPNext session (CVSS PR:L), meaning the attacker must possess or obtain at least a low-privilege application account before reaching the affected endpoints - this is the primary limiting factor. Beyond authentication, no special non-default configuration is indicated; the flaw stems from missing input validation on 'some endpoints' in ERPNext versions before 15.98.0 and 16.x before 16.6.0, so default deployments on those versions are affected once the attacker is logged in. Exposure is highest on internet-facing ERPNext instances with self-service or weakly provisioned accounts; instances restricted to trusted internal users and network segmentation reduce realistic risk. No end-user interaction is required (UI:N).

This is a credible but moderate-priority issue rather than an emergency. The supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) describes a network-reachable, low-complexity SQL injection that requires low-level authentication (PR:L) and yields high confidentiality impact with no integrity or availability impact - consistent with the description's framing of data extraction by 'remote authenticated attackers,' so the signals agree internally. No CISA KEV listing and no public exploit were provided, and no EPSS score was supplied, so there is no evidence of active or at-scale exploitation at this time. The main risk drivers are the low privilege barrier (any authenticated ERPNext user may suffice) and the CWE-89 injection class, which is highly reliable to weaponize once endpoints are identified; however, the requirement for valid credentials and the confidentiality-only impact keep real-world urgency below that of an unauthenticated RCE. Missing data: EPSS probability and POC status are absent and should be monitored, as a published exploit would materially raise priority given how automatable SQLi typically is.

An attacker who holds any valid low-privilege ERPNext account (or phishes/registers one on an exposed instance) sends specially crafted parameters to one of the vulnerable endpoints that lack input validation. The injected SQL manipulates the backend query to read data the user is not authorized to see, such as other tenants' records, credentials, or financial/HR data. No public proof-of-concept was identified at the time of analysis, but SQL injection with network reach and low privileges is straightforward to develop and automate.