ERPNext CVE-2026-72907

Exploitation requires a valid authenticated ERPNext user session at any privilege level - the lowest-privilege role is sufficient (PR:L). No special configuration, non-default feature enablement, or elevated access is needed beyond a working ERPNext installation with user accounts active. The add_ac function is reachable via ERPNext's standard Frappe API surface in default deployments. What limits exploitation: the attacker must possess valid ERPNext credentials (anonymous or external attackers cannot exploit this without first obtaining credentials through a separate attack); impact is bounded to integrity of Account master records only, with no confidentiality exposure (C:N) and no availability impact (A:N); and the attacker cannot escalate further within the system through this flaw alone.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N) yields a 6.5 Medium score, which underrepresents real-world business risk in financial environments. The I:H rating is the critical signal: an attacker can insert arbitrary Account master records into the chart of accounts, potentially enabling ghost accounts for financial fraud, distorting ledger balances, or corrupting audit trails used for regulatory compliance. For organizations subject to SOX, IFRS, or similar financial reporting standards, integrity compromise of accounting master data carries consequences far beyond a typical 6.5-rated vulnerability. The PR:L requirement - any valid authenticated session - is a meaningful but low barrier in enterprise ERP deployments where dozens to hundreds of staff hold accounts. No EPSS data was provided in the input; EPSS cannot be confirmed or cited. CISA KEV listing is not confirmed; active exploitation has not been reported. No public exploit code has been identified, though the vulnerability mechanics are fully disclosed via the public GitHub PR diff, lowering the bar for motivated threat actors with ERPNext knowledge. No conflicting signals exist between the CVSS vector and the described behavior.

An authenticated ERPNext user assigned a non-accounting role - such as a sales representative or inventory clerk - crafts a network request to the add_ac API endpoint and includes the ignore_permissions parameter in the request body. The function strips the permission check and creates the attacker-specified Account master record in the chart of accounts without triggering any authorization error. The attacker can repeat this to introduce ghost accounts or manipulate account hierarchies, with no public exploit code required given the mechanics are fully described in the public PR diff.