Frappe ERPNext EUVD-2026-98061

Requires an authenticated account with write access to item master data in ERPNext in order to store a malicious script in a record name (maps to PR:L). Exploitation does not fire until a victim operator subsequently opens the page that renders the unescaped record name (UI:P / passive interaction), so there is a dependency on a second, typically higher-privileged user viewing the affected item. Limiting factors: this is not remote-unauthenticated - the attacker must already hold item-write permissions (insider or compromised account), and impact is confined to the viewing operator's browser session rather than the ERPNext server. Affected: ERPNext before 15.110.0 and 16.x before 16.21.0; upgrading to 15.110.0 / 16.21.0 removes the condition.

This is a moderate-severity stored XSS (CWE-79) with a CVSS 4.0 base score of 5.1 (Medium), and the signals align consistently rather than conflicting. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) shows the weakness is network-reachable and low-complexity but gated by two real limiters: the attacker needs PR:L - authenticated write access to item master data - and exploitation requires passive user interaction (UI:P), namely an operator later opening the affected page. Impact is confined to the subsequent (victim browser) system with SC:L/SI:L and no impact to the vulnerable system itself (VC:N/VI:N/VA:N), reflecting a self-/stored-XSS that escalates only against other users. No EPSS score, CISA KEV listing, or public POC is present in the supplied intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Net assessment: this is a legitimate but not urgent fix - a privileged-insider or compromised-low-privilege-account vector against an ERP operator's session, not a mass-exploitable unauthenticated flaw. The low CVSS and the PR:L + UI:P gates argue against emergency prioritization; patch on a normal cycle unless the ERPNext instance grants item-write access broadly to untrusted users.

A user with write access to item master data (e.g., a low-privileged catalog editor or a compromised staff account) creates or edits an item and embeds a malicious script payload directly in the record name. When a higher-privileged operator later opens the page that renders that record name without escaping, the script executes in the operator's authenticated browser session, enabling session/action abuse within ERPNext. No public proof-of-concept exploit is identified in the supplied data.