Frappe ERPNext EUVD-2026-98001

Requires an authenticated account with permission to create the affected record type in Frappe ERPNext (versions before 15.112.0, or 16.x before 16.23.0), so exploitation is limited to insiders or attackers who have already obtained valid low-privilege credentials. The attacker must set a malicious record name, and the payload only executes when a second user subsequently opens the specific vulnerable tool view that interpolates stored record names into markup without escaping - meaning victim interaction is mandatory and no execution occurs until the tool is opened. Limiting factors: no unauthenticated path, required create-permission, and dependence on a victim navigating to the affected tool.

This is a moderate-priority, authentication-gated stored XSS (CWE-79) rather than a drop-everything emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H) scores 8.5 and signals network reach with low attacker privilege, but two factors temper real-world urgency: PR:L means the attacker must already be an authenticated ERPNext user who can create the affected records, and UI:P means exploitation only fires when another user passively opens the affected tool view. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. The VC:H/VI:H impact rating in the input appears aggressive for a reflected-in-session XSS; stored XSS typically yields partial confidentiality/integrity loss scoped to the victim's authenticated session rather than full system compromise, so defenders should treat the 8.5 as an upper bound. Net: a credible insider or low-privilege account-takeover vector worth patching in normal cycles, not a widely-weaponized remote-unauth flaw.

A low-privileged but authenticated ERPNext user creates a record (e.g., a document whose name is attacker-controlled) and embeds a malicious script payload in its name field. When an administrator or other user later opens the vulnerable tool view, the unescaped record name is interpolated into the page markup and the script executes in that victim's authenticated session, enabling session theft or actions on their behalf. No public exploit code was identified in the provided data, and success depends on a victim opening the affected tool (UI:P).