pacioli: Znacznik zgody na zatwierdzenie zezwalał na anulowanie istniejących dokumentów wskazanych przez wywołującego

Wpływ

Bramka zgody na poziomie dokumentów w pacioli-guard wymaga utworzonego przez człowieka, jednorazowego, powiązanego z dokumentem oraz powiązanego z czynnością znacznika, zanim poświadczenie z uprawnieniem API Key Scope.require_consent będzie mogło zatwierdzić lub anulować dokument. Ponieważ ERPNext wykonuje dalsze operacje zapisu dokumentów w następstwie kontrolowanej czynności, czynności zagnieżdżone mogą skorzystać z uprawnień (ride) zgody ustanowionej przez czynność nadrzędną, zamiast wymagać własnego znacznika.

Predykat przejęcia zgody zwracał true dla każdego anulowania, niezależnie od tego, na jaką czynność zezwalał znacznik nadrzędny. Przejęcie zgody nigdy nie dociera do consent_verdict, gdzie wymuszane jest powiązanie znacznika z czynnością. W rezultacie każda operacja Document.cancel() wykonana wewnątrz czynności z ustaloną zgodą docierała do docstatus = 2 bez znacznika, bez weryfikacji powiązania czynności, bez jednorazowego zużycia i bez wpisu audytowego o odmowie.

Ścieżka ta jest dostępna przy dokładnie takim zestawie uprawnień, jaki zgodnie z dokumentacją operator nadaje brokerowi, a tożsamość anulowanego dokumentu jest kontrolowana przez wywołującego:

• Sales Invoice.on_submit (sales_invoice.py:507) bezwarunkowo wywołuje process_asset_depreciation(), dochodząc do depreciate_asset_on_sale (:1508-1516).
• Następnie iteruje po wierszach pozycji faktury i wywołuje frappe.get_doc("Asset", d.asset). Pole Sales Invoice Item.asset jest zwykłym zapisywalnym Link bez read_only oraz fetch_from, więc wywołujący przekazuje je w treści żądania. Walidacja, która mogłaby je ograniczyć, znajduje się za if d.is_fixed_asset: (:428-429), polem ustawianym przez serwer.
• Łańcuch dociera do depreciation.py:481, a następnie do asset_depreciation_schedule.py:215-217, co wywołuje current_schedule.cancel() na docstatus == 1, zatwierdzalnym Asset Depreciation Schedule poprzez cykl życia dokumentu (ustawione jest tylko should_not_cancel_depreciation_entries, a nie ignore_validate, w związku z czym before_cancel jest wywoływane i to przejęcie zgody umożliwiło wykonanie operacji).

W ten sposób jeden znacznik autoryzujący submit Sales Invoice X anulował zatwierdzony dokument, którego człowiek nigdy nie widział ani nie zatwierdził. Anulowanie takiego dokumentu cofa jego skutki w księdze głównej.

Taki sam schemat występuje przy szerszych uprawnieniach, na przykład Unreconcile Payment.on_submit (unreconcile_payment.py:59-64), który iteruje po tabeli podrzędnej wypełnianej przez wywołującego i osiąga accounts/utils.py:857/:859 gain_loss_je.cancel() na zatwierdzonych wpisach do księgi (Journal Entries).

Kogo dotyczy problem

Problem dotyczy wyłącznie instancji, które włączyły bramkowanie zgód: poświadczenie musi posiadać API Key Scope z ustawionym require_consent. Mechanizm pacioli-guard jest nieaktywny dla podmiotów bez takiego uprawnienia, a bazowy zakres poświadczeń (auth_hooks) pozostaje nienaruszony.

Bramka zgody na poziomie dokumentu została po raz pierwszy opublikowana w 0.9.6, co stanowi jedyną wydaną wersję w podatnym zakresie.

Ryzyko rezydualne

W ramach kontrolowanego anulowania kaskadowe anulowanie wcześniej istniejącego dokumentu nadal korzysta z przejętej zgody. Jest to kluczowe dla operacji cofania (zwykłe anulowanie faktury powoduje, że ERPNext anuluje powiązane noty kredytowe/debetowe i wpisy księgowe za pośrednictwem accounts_controller.py:2001-2005) i nie może zostać zawężone bez sygnału, że kaskadowe anulowanie jest bezpośrednią konsekwencją dokumentu nadrzędnego. Uzasadnienie to nie obejmuje jednak wszystkich dopuszczanych przypadków: co najmniej jeden z nich może być kontrolowany przez wywołującego w taki sam sposób jak omawiana podatność: Asset Repair.on_cancel (asset_repair.py:215-222), który anuluje Serial and Batch Bundle wskazany przez powiązanie (Link) uzupełniane w tabeli podrzędnej. pacioli-guard nie obejmuje również operacji zapisu ustawiających flags.ignore_validate ani takich, które całkowicie pomijają cykl życia dokumentu (bezpośredni SQL, zapisy pól przez db_update/db_set); te ograniczenia są opisane w dokumentacji projektu i pozostają niezmienione.

Podziękowania

Podatność wykryta podczas wewnętrznego przeglądu bezpieczeństwa w dniu 2026-07-28, który przeanalizował predykat w kodzie źródłowym frappe 16.28.0 i ERPNext v16, a nie tylko w dokumentacji projektu. Poprzedni komentarz w kodzie zakładał brak takich mechanizmów, co sformułowano bez wcześniejszej analizy źródeł.