Frappe ERPNext CVE-2026-109622

Requires a valid authenticated ERPNext account with at least low-privilege access (CVSS PR:L) - anonymous/unauthenticated exploitation is NOT possible. The attacker must reach specific endpoints that fail to enforce role-based authorization and send requests to modify data outside their assigned role. Limiting factors: a valid authenticated session is mandatory, no user interaction of a victim is needed (UI:N), impact is confined to data integrity (VI:L) with no confidentiality or availability effect, and only ERPNext versions before 15.121.0 and 16.x before 16.34.0 are affected. The description does not name the exact vulnerable endpoints, so defenders cannot scope specific features without the vendor advisory.

This is a moderate-severity, authorization-bypass (broken access control) flaw, not a critical issue. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) scores 5.3 (Medium) and tells a consistent story: network-reachable and low-complexity, but it requires an already-authenticated low-privilege account (PR:L) and yields only limited integrity impact (VI:L) with no confidentiality (VC:N) or availability (VA:N) consequences. No EPSS score was provided, so statistical exploitation probability cannot be weighed. The CVE is NOT on CISA KEV and no proof-of-concept is referenced, so there is no evidence of active or imminent exploitation - this is a prioritize-with-your-normal-patch-cycle issue rather than an emergency. The main counterweight to the low raw score is that ERPNext deployments often have many authenticated internal users, which enlarges the pool of potential abusers; a malicious or compromised low-privilege employee account is the realistic threat, not an anonymous internet attacker. Note the 'Authentication Bypass' tag is imprecise: the CWE-862 (Missing Authorization) classification and the description both describe an AUTHORIZATION/privilege-escalation flaw affecting already-authenticated users, not a true authentication bypass.

An authenticated user with a limited ERPNext role (e.g., a standard staff account) discovers that certain backend endpoints do not verify their role before processing requests. They send crafted requests directly to those endpoints to alter documents or records they should not be permitted to change, undermining data integrity. No public exploit code is referenced, and exploitation requires a valid low-privilege session rather than anonymous access.