Frappe ERPNext CVE-2026-109671

Exploitation requires: (1) an authenticated low-privilege account with access to edit the vulnerable profile field - ERPNext deployments that enable self-service portal/website user accounts (customers, suppliers) are exposed, while instances restricting account creation are far less so; and (2) user interaction from a victim - specifically an administrator must view the portal page that renders the stored field (UI:P). The flaw is in a profile field rendered without output escaping into portal pages, so it is not exploitable against default configs that do not expose portal account self-registration. Limiting factors: the required low-privilege authentication and the dependence on an admin actually viewing the poisoned page bound real-world risk below that of a pre-auth, zero-interaction XSS.

This is a credible, moderately high-priority vulnerability but not an emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:P/VC:H/VI:H) rates it 8.5 (High): network-reachable, low attack complexity, but it requires an authenticated low-privilege account (PR:L) AND passive user interaction (UI:P) - specifically an administrator must view the page where the payload is stored. These two gating factors meaningfully reduce real-world exploitability versus a pre-auth no-interaction flaw. No EPSS score was provided, so exploitation probability cannot be quantified. The CVE is NOT in CISA KEV and no public POC is referenced, so this is 'no public exploit identified at time of analysis' - the high score reflects potential impact (full admin account takeover via stored XSS, hence VC:H/VI:H) rather than confirmed active exploitation. The signals are internally consistent: a stored XSS leading to privileged account takeover legitimately warrants a High rating, but absence of KEV/POC/EPSS data means prioritization should be driven by exposure (does your ERPNext instance allow low-privilege self-service portal accounts?) rather than by evidence of mass exploitation. Scope is unchanged (SC/SI/SA:N) because impact stays within the ERPNext application trust boundary.

A low-privilege user (e.g. a customer or supplier with a portal account) edits a profile field and injects a malicious script instead of normal text. The payload is stored and later rendered unescaped when an administrator opens the portal page displaying that profile, executing attacker JavaScript in the admin's authenticated session and enabling session/account takeover. No public exploit code is referenced, but stored XSS of this kind is trivially weaponizable once the vulnerable field is known.