Frappe ERPNext EUVD-2026-98014

Exploitation requires a valid authenticated ERPNext account with at least low-privilege role access (PR:L) and access to the specific endpoints that fail to enforce authorization checks. There is no user-interaction requirement (UI:N) and no special non-default configuration is named in the advisory - the flaw lies in the endpoints' own missing role enforcement. Limiting factors: the attacker must already possess working credentials, the impact is confined to modifying documents/data beyond the attacker's assigned role (low integrity/confidentiality impact, no availability impact), and affected deployments must run a version prior to 15.121.1 or 16.x prior to 16.34.2.

This is a moderate, authenticated access-control flaw (CWE-862, missing authorization) rather than a high-urgency issue. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N) aligns well with the description: network-reachable, low complexity, but requiring an already-authenticated low-privilege account (PR:L) and yielding only low confidentiality and integrity impact with no availability impact. No EPSS score, CISA KEV listing, POC, or SSVC decision data was supplied, so there is no signal of active or probable exploitation - exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent (no CVSS-vs-description conflict), and the low impact metrics indicate a privilege-boundary violation (an authenticated user acting beyond their assigned role) rather than full compromise. Priority is driven by context: organizations running ERPNext with many low-trust user accounts should patch promptly, but this is not a mass-exploitation 'drop everything' flaw. Note: no EPSS data was provided, so widespread-exploitation likelihood cannot be quantified from the input.

A low-privileged but authenticated ERPNext user (for example, a limited sales or support account) sends crafted requests directly to the affected endpoints that skip role-based authorization checks, modifying documents or records their role should not permit - such as altering financial or HR documents. No public exploit code was identified, and the attack requires valid credentials and some knowledge of the vulnerable endpoints.