Frappe ERPNext EUVD-2026-98048

The attacker must be an authenticated ERPNext user holding edit (write) rights on a document type, allowing them to set a record's name field to a script payload that is rendered without HTML escaping. Exploitation further requires that a second user (a colleague) subsequently opens the page displaying that record name (UI:P), at which point the script runs in the victim's session. Limiting factors: no anonymous/unauthenticated path (edit rights required), reliance on victim interaction to trigger the payload, and impact confined to the browser session rather than the ERPNext server itself. Fixed in version 16.27.0.

This is a medium-severity, authenticated stored XSS (CWE-79) in Frappe ERPNext 16.x before 16.27.0, and the available signals converge on a genuine-but-limited priority rather than an urgent emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) confirms network reach and low complexity but requires PR:L - the attacker must already hold edit rights on records - and UI:P, meaning a victim colleague must open the affected page. Impact is scoped to the subsequent system (the victim's browser session): SC:L/SI:L with VC/VI/VA:N on the vulnerable server itself, consistent with script execution in another user's context rather than direct server compromise. No EPSS score, KEV listing, or POC was provided in the input: exploitation status is 'no public exploit identified at time of analysis.' The authenticated precondition (edit rights) substantially lowers real-world risk since it presumes an insider or a compromised/over-privileged account, making this most relevant as a privilege-escalation or lateral-movement primitive within an ERP tenant rather than a mass-exploitable external flaw. No signals conflict; the main caveat is simply the absence of exploitation-probability data (EPSS/KEV/POC all unknown).

A low-privileged ERPNext user who holds edit rights on a document type creates or renames a record so its name contains a malicious script payload. When a colleague - potentially an administrator - later opens that record's page, the unescaped record name renders and the script executes in their authenticated session, enabling session actions or data theft in the victim's browser context. No public exploit code was identified in the provided data.