Frappe ERPNext EUVD-2026-98059

Requires a valid authenticated account with a low-privileged role on the target ERPNext instance (PR:L) running a version before 15.110.0 or a 16.x version before 16.21.0; the attacker then sends requests to the specific party-record handling endpoints that omit server-side authorization enforcement. Limiting factors: no anonymous/pre-auth path (an account is mandatory), impact is confined to unauthorized modification of party records with no confidentiality or availability effect, and instances on 15.110.0+/16.21.0+ are not affected. No special non-default configuration is indicated as required by the description.

This is a genuinely medium/low-priority issue, not a high-urgency flaw. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 and shows the only impact is low integrity (VI:L) - no confidentiality (VC:N) and no availability (VA:N) loss, with no scope change to subsequent systems. PR:L means the attacker must already hold a valid authenticated (low-privileged) account, which substantially limits the exploit population to insiders or holders of compromised/low-trust credentials rather than anonymous internet attackers. No EPSS score, CISA KEV listing, or POC/exploit-code signal was provided in the input, so there is no evidence of active or at-scale exploitation - the exploitation status is simply unknown, not low. The CWE (CWE-862 Missing Authorization) is consistent with the description and the PR:L vector: this is a horizontal/vertical privilege-authorization gap on specific endpoints, not a pre-auth compromise. Net: a real data-integrity authorization defect worth patching in normal cycles, but absent any exploitation telemetry it does not rise to emergency priority.

A user holding a low-privileged ERPNext role (for example a limited employee or a self-registered/portal account) sends requests directly to the affected party-record endpoints, which fail to enforce role-based authorization server-side, and alters customer, supplier, or other party records they should not be able to change. Because the vector is network-based with low attack complexity (AV:N/AC:L) and no user interaction, the request can be scripted once a valid session exists. No public exploit code was identified at time of analysis.