CVE-2026-107841 in pacioli
Summary
by MITRE • 10/09/2026
pacioli provides least-privilege governance and a governed agent broker for ERPNext. From version 0.9.6 until version 0.10.0, the pacioli-guard document-layer consent gate allows nested cancellation operations to ride any consent established by an enclosing governed act without checking whether the marker authorizes cancellation. A credential with API Key Scope.require_consent can submit a caller-controlled Sales Invoice or other supported document under a valid human-minted submit marker and reach Document.cancel() for a different pre-existing submitted document, bypassing the marker's document and act binding, single-use spend, and denial audit. The unauthorized cancellation can reverse the target document's ledger effect; principals without a consent-gated grant are not affected. This issue is fixed in version 0.10.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified within Pacioli versions ranging from 0.9.6 to 0.10.0 represents a critical failure in the enforcement of least-privilege governance principles, specifically concerning the document-layer consent gate mechanism known as pacioli-guard. This component is designed to act as an agent broker for ERPNext systems, ensuring that actions taken by automated agents or API calls are subject to human-minted consents and strict authorization boundaries. The core technical flaw lies in how nested cancellation operations interact with existing consent markers. When a caller submits a controlled document, such as a Sales Invoice, under the umbrella of a valid submit marker intended for a different purpose, the system incorrectly allows this action to inherit broader permissions than those explicitly granted by the enclosing governed act. Specifically, the logic fails to verify whether the specific marker authorizes cancellation operations, thereby permitting unauthorized state changes on pre-existing submitted documents that were not part of the original consent scope.
From an operational perspective, this flaw enables a significant bypass of security controls including document binding, single-use spend limits, and denial auditing mechanisms. An attacker possessing an API key with the Scope.require_consent attribute can exploit this logic error to target any accessible document within the ERPNext environment rather than being restricted to the specific document intended by the consent marker. By leveraging the valid submit context of one document, the adversary can invoke Document.cancel() on a completely different pre-existing submitted document. This unauthorized cancellation effectively reverses the financial ledger effects associated with that target document, potentially leading to severe data integrity issues, inaccurate financial reporting, and loss of audit trails. The impact is particularly acute because it allows principals who lack explicit consent-gated grants for cancellation to achieve this outcome through privilege escalation via context manipulation.
This vulnerability aligns closely with CWE-269 Improper Privilege Management, as the system fails to properly restrict administrative or destructive actions based on user roles and specific permissions. Furthermore, the exploitation technique reflects aspects of ATT&CK T1078 Valid Accounts, where an attacker uses legitimate credentials but manipulates their usage context to perform unauthorized activities. The failure also touches upon CWE-924 Improper Enforcement of Message Integrity During Processing in a Context-Dependent Manner, as the integrity checks for consent markers are bypassed through nested operation abuse. To mitigate this risk, organizations must upgrade immediately to version 0.10.0 or later where the logic has been corrected to strictly validate cancellation permissions against the specific document and act binding of each individual marker. Until such an update is applied, administrators should enforce strict network segmentation for ERPNext instances, limit API key scopes to the minimum necessary privileges, and implement rigorous manual auditing of all cancellation events to detect any potential exploitation attempts that may have occurred during the vulnerable window.