ERPNext EUVD-2026-103170

Requires a valid authenticated ERPNext account with any low-privilege role (PR:L) on the target instance; no admin rights, no user interaction, and no non-default configuration are needed because the affected whitelisted methods (e.g. Ledger Merge start_merge, Process Period Closing Voucher start/pause/cancel, Repost Payment Ledger, Delivery Note make_sales_return, payment order, and bulk transaction processing) are standard endpoints. Exploitation is LIMITED by the need for an existing account - fully unauthenticated attackers cannot trigger it - so risk concentrates in multi-user or externally-accessible ERPNext deployments where untrusted or low-trust users can log in; affected only on versions prior to 15.121.0 and 16.34.0.

This is a genuine authorization flaw (CWE-862, Missing Authorization) in ERPNext whose exploitability profile is confirmed by the vendor via the GitHub Security Advisory (GHSA-5wpj-6rvp-9ff7) and three fix commits. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N, 7.7) is internally consistent with the description and the source-code evidence: whitelisted state-changing methods (start_merge, PCV processing, payment-ledger repost, sales-return creation, bulk transactions) lacked check_permission/has_permission/only_for guards, so a low-privileged authenticated user (PR:L) can invoke them remotely (AV:N) with no user interaction (UI:N) to modify data outside their role - a scope change (S:C) with high integrity impact and no confidentiality or availability impact (C:N/I:H/A:N). No EPSS score, KEV listing, or SSVC decision data was supplied, and no public exploit is referenced, so there is no evidence of active exploitation or automatable mass-scanning; this is a high-CVSS integrity/access-control bug whose real-world risk is bounded by the requirement for an existing authenticated account on the target instance. Priority is moderate-to-high for internet-exposed multi-tenant ERPNext deployments where low-trust users hold accounts, but lower for single-tenant internal installations.

A low-privileged authenticated ERPNext user (for example a basic sales or project user) directly calls one of the affected whitelisted server methods - such as the Delivery Note sales-return creation, payment-order, or period-closing-voucher endpoints - over the normal web API. Because the pre-patch code skipped write/submit/cancel permission checks, the request succeeds and mutates financial or stock documents the user has no role to touch. No public exploit code is referenced, but the vendor fix commits reveal the exact unguarded methods, making weaponization straightforward for an authenticated actor.