Frappe ERPNext EUVD-2026-98053

Requires an ERPNext instance exposing a public portal form that accepts unauthenticated submissions and stores the content for later back-office review (e.g. a web-facing intake/request form) - if no such portal form is published, the unauthenticated entry point does not exist. Exploitation is NOT self-triggering: the stored payload only executes when an authenticated staff member subsequently opens the malicious record in their browser (CVSS UI:P), so a human review action is a hard prerequisite. Impact is confined to the reviewing user's browser session (subsequent-system SC:L/SI:L); there is no direct server-side confidentiality, integrity, or availability impact (VC:N/VI:N/VA:N). Patched in ERPNext 15.112.0 and 16.23.0.

This is a medium-severity (CVSS 4.0 base 5.3) stored cross-site scripting flaw whose signals are consistent and point to a moderate, not critical, priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P) confirms a network-reachable, low-complexity, unauthenticated submission path, which is attractive because anyone on the internet can plant the payload; however the impact metrics are deliberately modest (VC:N/VI:N/VA:N on the vulnerable system, with only SC:L/SI:L on the subsequent system - i.e. the staff member's browser session), reflecting that this is a client-side script-execution issue rather than direct server compromise. Critically, exploitation is gated by UI:P: the payload only fires when a staff member later reviews the malicious record, so there is a human-in-the-loop delay and no guaranteed automatic trigger. No EPSS score, CISA KEV listing, SSVC decision, or public POC was provided in the input, so there is no evidence of active exploitation or automatable mass exploitation - exploitation status is therefore 'no public exploit identified at time of analysis'. The absence of KEV/EPSS data is a genuine gap (absence is not proof of safety), but nothing in the data elevates this above a standard, patch-on-normal-cadence stored XSS. Net: a real but bounded issue - worth patching, especially in internet-facing portals, yet not an emergency.

An unauthenticated attacker locates an ERPNext public portal form that accepts submissions (e.g. a web-facing request/intake form) and submits a record containing crafted HTML/JavaScript markup instead of benign text. When a staff member later opens the backend to review that stored submission, the insufficiently neutralised markup renders and executes in the reviewer's authenticated browser session, enabling session-context actions such as cookie/token theft or UI manipulation. No public exploit code was identified at time of analysis, so this scenario is inferred from the description and CVSS vector rather than a published POC.