Frappe ERPNext EUVD-2026-98011

Exploitation requires a valid authenticated account on the ERPNext instance with at least low-privilege access (PR:L), and the attacker must target the specific document-creation endpoints that omit role-based authorization checks. The limiting factors are: the attacker must already possess credentials (no unauthenticated access), exploitation is bound to vulnerable versions (ERPNext before 15.121.0 or 16.x before 16.34.0), and impact is confined to unauthorized document creation beyond the user's permitted role rather than full administrative takeover. Deployments that allow self-registration or grant portal/customer accounts broaden the realistic attacker pool.

This is a genuine but moderate-priority issue, best characterized as a privilege/authorization problem rather than a critical remote-code flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms network-reachable, low-complexity exploitation but requires an already-authenticated low-privileged account (PR:L), which materially limits the attacker population to existing users of the ERPNext instance. Impact is skewed toward integrity (VI:H - unauthorized document creation beyond role) with only limited confidentiality exposure (VC:L) and no availability or scope impact, consistent with CWE-862 Missing Authorization. No EPSS score, KEV listing, or POC indicator was supplied in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the 7.1 score is driven by the integrity impact combined with easy, authenticated network access, not by mass-exploitation signals. In short, this is a real but contained insider/low-privilege escalation risk - prioritize patching for multi-tenant or externally-registered ERPNext deployments, but it is not a drop-everything internet-wide emergency absent any EPSS/KEV/POC evidence.

A low-privileged authenticated user (e.g., a restricted employee or a self-registered portal account) sends a crafted request to one of the affected document-creation endpoints. Because the endpoint fails to enforce role-based permission checks, the request succeeds in creating records the user should not be able to touch, letting them inject or manipulate business documents outside their assigned role. No public exploit code was identified in the provided data.