pacioli: A submit consent marker licensed cancellation of caller-named pre-existing documents
🔗 CVE IDs covered (1)
📋 Description
Impact
pacioli-guard's document-layer consent gate requires a human-minted, single-use, document-bound and act-bound marker before a credential carrying API Key Scope.require_consent may submit or cancel a document. Because ERPNext performs further document writes as a consequence of a governed act, nested acts are allowed to "ride" the consent established by the enclosing act instead of needing a marker of their own.
The ride predicate returned true for every cancel, regardless of which act the enclosing marker authorised. Riding never reaches consent_verdict, which is where the marker-to-act binding is enforced. The result: any Document.cancel() performed inside an act that had established consent reached docstatus = 2 with no marker, no act-binding check, no single-use spend, and no denial audit row.
This is reachable with the exact grant an operator is documented to give the broker, and the cancelled document's identity is caller-controlled:
Sales Invoice.on_submit(sales_invoice.py:507) callsprocess_asset_depreciation()unconditionally, reachingdepreciate_asset_on_sale(:1508-1516).- That iterates the invoice's item rows and calls
frappe.get_doc("Asset", d.asset).Sales Invoice Item.assetis a plain writableLinkwith noread_onlyand nofetch_from, so the caller supplies it in the request body. The validation that would constrain it sits behindif d.is_fixed_asset:(:428-429), a server-set field. - The chain reaches
depreciation.py:481and thenasset_depreciation_schedule.py:215-217, which callscurrent_schedule.cancel()on adocstatus == 1, submittableAsset Depreciation Schedulethrough the document lifecycle (onlyshould_not_cancel_depreciation_entriesis set, notignore_validate, sobefore_canceldoes fire and the ride is what admitted it).
So one marker authorising submit Sales Invoice X cancelled a submitted document the human was never shown and never approved. Cancelling such a document reverses its ledger effect.
The same shape exists behind wider grants, for example Unreconcile Payment.on_submit (unreconcile_payment.py:59-64), which walks a child table the caller fills and reaches accounts/utils.py:857/:859 gain_loss_je.cancel() on submitted Journal Entries.
Who is affected
Only sites that had opted into consent gating: a credential must hold an API Key Scope with require_consent set. pacioli-guard is inert for principals without such a grant, and the credential-scoping floor (auth_hooks) is unaffected by this issue.
The document-layer consent gate was first published in 0.9.6, which is the only released version in the affected range.
Patches
Fixed in 0.10.0. The ride now discriminates on the enclosing act: an undo may cascade into further undos, but a submit may not cascade into the cancellation of a document that already has a name, because that is an act a human could have been asked to approve. The custody stamp carries the act it was established for rather than a bare boolean, which is the state the vulnerable code lacked.
Upgrading changes behavior. Any ERPNext flow where a submit cascades into a lifecycle cancel now requires a consent marker for that cancel as well as for the act itself. In ERPNext v16 that includes asset sale, partial-quantity asset sale, a credit note against an asset sale, Asset Repair capitalization, Asset Shift Allocation, Asset Value Adjustment, and Unreconcile Payment. To make that possible, the X-Pacioli-Consent header now accepts several markers separated by whitespace or commas; each remains bound to one document and one act, requires a different minter, and is spent exactly once.
Workarounds
On 0.9.6, remove require_consent from affected grants and rely on the credential-scoping floor alone, or scope governed credentials so they cannot submit documents whose controllers cancel other documents (for ERPNext slice-one, Sales Invoice with a populated item-row asset link is the known path). Neither is a substitute for upgrading.
Residual, stated
Under a governed cancel, a cascaded cancel of a pre-existing document still rides. That is load-bearing for undo (an ordinary invoice cancel makes ERPNext cancel the credit/debit notes and journals it generated, via accounts_controller.py:2001-2005) and cannot be narrowed without a signal that a cascaded cancel is a consequence of the enclosing document specifically. That justification does not describe everything the residual admits: at least one instance is caller-steered in the same shape as the issue fixed here, Asset Repair.on_cancel (asset_repair.py:215-222), which cancels a Serial and Batch Bundle named by a Link the caller fills in a child table. pacioli-guard also does not see writes that set flags.ignore_validate or that skip the document lifecycle entirely (raw SQL, db_update/db_set field writes); those residuals are published in the project's own documentation and are unchanged by this advisory.
Credit
Found by an internal adversarial review on 2026-07-28 that traced the predicate against frappe 16.28.0 and ERPNext v16 source rather than the project's own documentation. The prior code comment asserted that no such lever was known; that assertion had been written without the corresponding source sweep.
🎯 Affected products1
- pip/pacioli-guard:>= 0.9.6, < 0.10.0
🔗 References (5)
- https://github.com/john-broadway/pacioli/security/advisories/GHSA-3hj7-6vmj-h8v4
- https://nvd.nist.gov/vuln/detail/CVE-2026-107841
- https://github.com/john-broadway/pacioli/commit/f3c7219f5dde6050bd7921e0ac55afd02771250c
- https://github.com/john-broadway/pacioli/releases/tag/guard-v0.10.0
- https://github.com/advisories/GHSA-3hj7-6vmj-h8v4