Frappe ERPNext EUVD-2026-98039

Exploitation requires an authenticated ERPNext session with at least low-level privileges (PR:L) - the attacker must already possess or obtain valid application credentials. The flaw lies in specific endpoints that perform missing input validation, allowing SQL injection into database queries; it affects ERPNext versions before 15.106.0 and 16.x before 16.16.0. Limiting factors: valid authentication is mandatory (ruling out anonymous internet scanning), and impact is confined to confidentiality (data extraction) with no inherent write/integrity or availability effect. Realistic risk is highest for internet-exposed instances that provision self-service or broad low-privilege user accounts; instances restricted to a small set of trusted internal users face lower exposure.

This is a genuine but moderate-priority issue rather than a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) tells a consistent story: network-reachable, low attack complexity, no user interaction, but requiring low-level authenticated privileges (PR:L) and causing confidentiality impact only (VC:H) with no integrity or availability damage. That aligns with the description - an authenticated SQL injection enabling extraction of sensitive data. The 7.1 score is driven by the high confidentiality impact, not by unauthenticated access. No EPSS score, CISA KEV listing, or POC reference was provided in the input, so exploitation likelihood signals are absent: there is no public exploit identified at time of analysis and no evidence of active exploitation. The requirement for valid authentication (PR:L) meaningfully limits widespread opportunistic exploitation, though any legitimate low-privileged ERPNext user - or an attacker who has phished/compromised one such account - could leverage it. Net: a real vulnerability worth patching promptly for internet-exposed ERPNext instances, but not a drop-everything KEV-grade threat based on the signals supplied. Note the absence of EPSS/KEV/POC is a data gap, not evidence of low risk.

An attacker with a valid low-privileged ERPNext account (e.g., a standard user, or a compromised employee credential) sends a specially crafted request to one of the affected endpoints that lacks input validation, injecting SQL into a backend query. Because low attack complexity applies and no user interaction is needed, the attacker can iteratively extract sensitive records - customer data, financial entries, or credential hashes - directly from the underlying database. No public exploit code was identified in the provided intelligence.