Frappe ERPNext CVE-2026-109611

Requires a valid authenticated ERPNext session with at least a low-privilege role (PR:L); the vulnerability is reachable over the network against the application's affected endpoints and needs no user interaction or special non-default configuration per the available data. Exploitation is limited to Frappe ERPNext versions before 15.121.0 and 16.x before 16.34.0 - patched instances are not affected - and the flaw only permits data modification beyond the attacker's assigned role, not credential-less access, so an attacker must first obtain or possess working low-tier credentials (insider, compromised account, or self-service portal/customer registration where enabled).

This is a moderate-severity authorization flaw (CWE-862, vendor CVSS 4.0 base 5.3) that should be treated as a patch-in-normal-cycle issue rather than an emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates network-reachable, low-complexity exploitation but requires an already-authenticated low-privilege account (PR:L), which meaningfully narrows the attacker population to insiders or anyone who has obtained valid low-tier ERPNext credentials. Impact is constrained to integrity only (VI:L; VC:N/VA:N), meaning data tampering beyond assigned role - not data theft or denial of service - so this is a horizontal/vertical privilege-escalation and data-manipulation concern, not a full system compromise. No EPSS score, no CISA KEV listing, and no public POC were provided in the intelligence, so there is no signal of active or widespread exploitation; this reads as a genuine but non-urgent authorization gap rather than a high-CVSS-but-low-real-risk false alarm. The main signals are consistent (network vector aligns with a web-based ERP, and PR:L aligns with the description's 'authenticated users'), so there is no internal contradiction to flag - the limiting factor is simply the authentication prerequisite and the integrity-only impact.

A low-privileged but legitimate ERPNext user (for example, a basic employee or a self-registered portal/customer account) sends a crafted request directly to one of the affected endpoints that omits a server-side authorization check. Because the endpoint does not verify the caller's role, the user modifies records they should not be permitted to change - such as financial, inventory, or HR data - escalating their effective privileges within the application. No public exploit code was identified at time of analysis, and exploitation requires valid credentials.