Frappe ERPNext CVE-2026-109673

Requires an authenticated account with permission to create or rename records whose names are later rendered on certain ERPNext dashboards, tools, or portal pages (PR:L). Exploitation is a stored/second-order XSS, so it only triggers when a victim - ideally a privileged user - views the page that renders the unneutralized record name (UI:P/passive interaction), meaning the attacker cannot control exact timing. Limiting factors: a valid low-privilege login is mandatory, the payload only fires against users who open the specific affected views, and installations on versions 15.103.0+ or 16.12.0+ are not vulnerable.

This is a credible, above-average-priority issue but not an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H) scores 8.5 (High) and is internally consistent with a stored XSS flaw: network-reachable, low complexity, but requiring low-privilege authentication (PR:L) and passive victim interaction (UI:P) - a victim must view an affected dashboard/tool/portal. These two gating factors (authentication plus required victim view) meaningfully lower real-world risk versus an unauthenticated, no-interaction RCE. No EPSS score, KEV listing, or POC was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation; exploitation probability signals are simply absent rather than contradictory. The highest-value outcome is session/token theft against privileged users, which can escalate to broad data access and modification - so impact is high even though the barrier to entry (a valid account that can name records) is moderate. Net: a real patching priority for internet-facing or multi-tenant ERPNext deployments, but it depends on an attacker already having an authenticated foothold, so it reads as elevated-but-not-critical absent exploitation evidence.

A low-privileged but authenticated ERPNext user (or a malicious tenant/vendor/customer with portal access) creates or renames a record using a name containing a malicious script payload. When a privileged user - such as a System Manager or Accounts Manager - later opens a dashboard, tool, or portal page that renders that record name without proper neutralization, the script executes in their browser, allowing session token theft and actions performed as the victim. No public exploit code was identified at time of analysis, so this would currently require custom payload development.