Frappe ERPNext EUVD-2026-98030

Exploitation requires an authenticated session with a valid low-privilege ERPNext account (CVSS PR:L); it is not exploitable by fully unauthenticated attackers. The attacker must reach one of the specific affected endpoints that lack input validation and submit crafted input that alters the backend SQL query. The affected deployments are ERPNext versions before 15.102.0 and 16.x before 16.8.0; upgrading to 15.102.0 or 16.8.0 removes the flaw. The limiting factor is the account requirement - an attacker needs legitimate (or compromised) credentials - while no special non-default configuration or user interaction is needed beyond holding such an account.

The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N, base 7.1) describes a network-reachable, low-complexity SQL injection that requires an authenticated low-privileged account (PR:L) and no user interaction, yielding high confidentiality impact but no integrity or availability impact - consistent with data extraction rather than full compromise. No EPSS score was provided, there is no CISA KEV listing, and no public POC is indicated, so the only concrete exploitation signal is the CVSS vector itself and VulnCheck's advisory. This places the issue as a genuine but moderate priority: SQL injection with network reach and low complexity is attractive, but the PR:L authentication requirement meaningfully narrows the attacker population to users who already hold a valid (even if low-privilege) ERPNext account, which argues against mass unauthenticated exploitation. Key missing data to note explicitly: no EPSS probability is available to gauge likelihood, and no exploitation-status evidence (KEV/POC) exists, so real-world weaponization cannot be confirmed from the provided data. The confidentiality-only impact (VI:N/VA:N) suggests information disclosure rather than database takeover, which should temper severity relative to a classic write-capable SQLi.

An attacker who has obtained or registered a low-privilege ERPNext account authenticates and sends specially crafted requests to one of the affected endpoints that fail to validate input. The injected SQL manipulates the backend query to return data the account should not have access to, enabling extraction of sensitive records from the database. No public exploit code is identified at time of analysis, and exploitation requires a valid low-privileged session.