ERPNext EUVD-2026-60453

Exploitation requires a valid ERPNext user account with permission to access the Inactive Customers report under the Selling module (CVSS PR:L confirms low-privilege authenticated access is sufficient). No elevated roles such as System Manager or Administrator are required - any standard sales user with report access is sufficient. The vulnerable code paths execute unconditionally when the report is run with a crafted doctype filter; no non-default configuration is required. Exploitation is limited by: (1) requirement for valid credentials, (2) the doctype parameter must bypass whatever front-end validation exists (the server performed none prior to the fix), and (3) scope is unchanged (S:U), meaning the injection is constrained to the ERPNext database and does not pivot to the OS or other systems.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L, score 7.6) accurately reflects the core risk profile: network-reachable, low complexity, requiring only a standard authenticated session. The High confidentiality impact is the dominant concern - ERP systems hold payroll, customer, financial, and supply chain data, making successful exploitation highly damaging. Integrity and availability impacts are rated Low, consistent with SQL injection limited to SELECT manipulation and minor DML side effects rather than full database write access. No EPSS data was provided in the source intelligence, and no CISA KEV listing exists, meaning confirmed active exploitation is absent. The attack is not automatable at scale since it requires valid ERPNext credentials, which limits mass exploitation - even a mid-sized municipal IT team in sanok managing an ERPNext deployment should treat this as urgent given the sensitivity of ERP data but need not invoke emergency incident response absent evidence of active exploitation. The CVSS score is appropriate and not inflated; the PR:L requirement is the primary exploitation limiter.

An authenticated ERPNext user with access to the Selling module navigates to the Inactive Customers report and submits a crafted doctype parameter value containing SQL payloads - for example, a UNION SELECT clause - instead of a legitimate doctype name such as 'Sales Order'. The application interpolates this value directly into the SQL query string, executing the attacker-controlled SQL against the database. This allows extraction of arbitrary table contents, including customer records, financial totals, and potentially credential-adjacent data from other Frappe doctypes.