Frappe ERPNext CVE-2026-109612

Exploitation requires an authenticated ERPNext account with permission to create records (PR:L), so it is not remote-unauthenticated; the attacker stores a malicious payload in a record's name field. Execution is further gated on a second user opening the specific report view that interpolates stored record names into markup without escaping (UI:P) - the payload lies dormant until then. Limiting factors: the attacker needs valid credentials and create-record rights, impact scales with the privilege of whichever user opens the report, and only the vulnerable report view path is affected. Affected deployments are ERPNext before 15.120.0 and 16.x before 16.33.0; patched versions remove the exposure.

This is a credible, moderately-high priority issue rather than an inflated high-CVSS score. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H) correctly reflects a stored XSS: network-reachable, low complexity, but gated by PR:L (the attacker must be an authenticated user permitted to create records) and UI:P (a victim must later open the affected report). The VC:H/VI:H rating is justified because script executing in a victim's ERPNext session - especially an administrator or finance user - can drive session hijacking, data exfiltration, and record manipulation across the ERP. No EPSS score, SSVC decision, KEV listing, or POC is present in the supplied data, so no public exploit identified at time of analysis and there is no evidence of active exploitation; the real-world urgency therefore rests on the plausibility of an insider or low-privilege account being used to plant the payload. Signals are internally consistent (no CVSS-vs-description conflict), but the absence of EPSS/KEV/POC means exploitation likelihood cannot be quantified from this input - treat the risk as 'needs patching promptly in multi-tenant or large-user ERPNext deployments' rather than 'emergency internet-facing RCE.'

A low-privileged but authenticated ERPNext user (or a compromised/rogue account) creates a record whose name field contains a crafted JavaScript payload. When a higher-privileged user such as an administrator later opens the report view that interpolates that record name into markup without escaping, the script executes in the victim's authenticated session, enabling session token theft or actions performed as that user. No public exploit code is identified in the provided data, and successful attack requires the victim to open the affected report (UI:P).