pacioli: Submit-Consent-Marker autorisierte die Stornierung von durch Aufrufer benannten bestehenden Dokumenten

Auswirkungen

Das Consent-Gate auf Dokumentenebene von pacioli-guard erfordert einen von Menschen generierten, einmalig verwendbaren, dokumenten- und aktionsgebundenen Marker, bevor Zugangsdaten mit API Key Scope.require_consent ein Dokument übermitteln oder stornieren dürfen. Da ERPNext als Folge einer gesteuerten Aktion weitere Schreibvorgänge auf Dokumente durchführt, dürfen verschachtelte Aktionen die durch die übergeordnete Aktion erteilte Einwilligung "mitnutzen" (ride), anstatt einen eigenen Marker zu benötigen.

Das Ride-Prädikat gab für jede Stornierung true zurück, unabhängig davon, welche Aktion der übergeordnete Marker autorisiert hatte. Das Mitnutzen erreicht niemals consent_verdict, wo die Bindung zwischen Marker und Aktion durchgesetzt wird. Die Folge: Jede Document.cancel(), die innerhalb einer Aktion mit bestehender Einwilligung ausgeführt wurde, erreichte docstatus = 2 ohne Marker, ohne Prüfung der Aktionsbindung, ohne einmaligen Verbrauch und ohne Audit-Eintrag für eine Verweigerung.

Dies ist mit genau den Berechtigungen erreichbar, die ein Administrator dem Broker laut Dokumentation zuweist, und die Identität des stornierten Dokuments wird vom Aufrufer gesteuert:

• Sales Invoice.on_submit (sales_invoice.py:507) ruft bedingungslos process_asset_depreciation() auf und erreicht depreciate_asset_on_sale (:1508-1516).
• Dies iteriert über die Positionszeilen der Rechnung und ruft frappe.get_doc("Asset", d.asset) auf. Sales Invoice Item.asset ist ein einfaches beschreibbares Link ohne read_only und ohne fetch_from, sodass der Aufrufer es im Request-Body übergeben kann. Die Validierung, die dies einschränken würde, liegt hinter if d.is_fixed_asset: (:428-429), einem serverseitig gesetzten Feld.
• Die Kette erreicht depreciation.py:481 und anschließend asset_depreciation_schedule.py:215-217, was current_schedule.cancel() auf einem docstatus == 1, übermittelbaren Asset Depreciation Schedule über den Dokumentenlebenszyklus aufruft (nur should_not_cancel_depreciation_entries ist gesetzt, nicht ignore_validate, sodass before_cancel ausgelöst wird und das Ride-Verhalten den Zugriff gestattet hat).

Somit stornierte ein Marker, der submit Sales Invoice X autorisierte, ein übermitteltes Dokument, das der Benutzer nie gesehen und nie genehmigt hatte. Das Stornieren eines solchen Dokuments macht dessen Hauptbucheintrag rückgängig.

Das gleiche Muster existiert bei weiter gefassten Berechtigungen, beispielsweise Unreconcile Payment.on_submit (unreconcile_payment.py:59-64), welches eine vom Aufrufer gefüllte untergeordnete Tabelle durchläuft und accounts/utils.py:857/:859 gain_loss_je.cancel() auf übermittelten Journalbuchungen erreicht.

Wer betroffen ist

Nur Instanzen, die das Consent-Gating aktiviert haben: Ein Berechtigungsnachweis muss ein API Key Scope mit gesetztem require_consent besitzen. pacioli-guard ist für Prinzipale ohne eine solche Berechtigung inaktiv, und die Mindesteinschränkung der Zugangsdaten (auth_hooks) ist von diesem Problem nicht betroffen.

Das Consent-Gate auf Dokumentenebene wurde erstmals in 0.9.6 veröffentlicht, was die einzige betroffene veröffentlichte Version darstellt.

Verbleibendes Restrisiko

Unter einer gesteuerten Stornierung greift das Mitnutzen für eine kaskadierte Stornierung eines bereits bestehenden Dokuments weiterhin. Dies ist essenziell für Rückgängigmachungen (eine gewöhnliche Rechnungsstornierung veranlasst ERPNext dazu, erzeugte Gutschriften/Lastschriften und Journale über accounts_controller.py:2001-2005 zu stornieren) und kann nicht eingeschränkt werden, ohne dass ein Signal vorliegt, dass die kaskadierte Stornierung eine direkte Folge des übergeordneten Dokuments ist. Diese Begründung deckt jedoch nicht alles ab, was das Restrisiko zulässt: Mindestens ein Fall kann auf dieselbe Weise vom Aufrufer gesteuert werden wie die hier behobene Schwachstelle: Asset Repair.on_cancel (asset_repair.py:215-222), was ein Serial and Batch Bundle storniert, das über einen vom Aufrufer in einer untergeordneten Tabelle ausgefüllten Link referenziert wird. pacioli-guard erfasst zudem keine Schreibvorgänge, die flags.ignore_validate setzen oder den Dokumentenlebenszyklus vollständig umgehen (rohes SQL, Feld-Schreibvorgänge via db_update/db_set); diese Restrisiken sind in der Projektdokumentation beschrieben und bleiben unverändert.

Danksagung

Entdeckt durch ein internes Audit am 2026-07-28, bei dem das Prädikat gegen den Quellcode von Frappe 16.28.0 und ERPNext v16 anstelle der Projektdokumentation geprüft wurde. Ein früherer Code-Kommentar ging davon aus, dass kein solcher Angriffspunkt existiert; diese Annahme basierte nicht auf einer Quellcode-Überprüfung.