Repository navigation
sec(purchase): constraint checks read recs before the CAS; execution buys from the post-CAS row (TOCTOU) #415
Description
Found in the review of #378. runPlannedPurchase (and the approve-any path) check permission Constraints (MaxPurchaseAmount etc.) against the recs loaded by GetExecutionByID, but executeAndFinalize buys from the row the CAS in RunPlannedPurchaseNow / ApproveAndExecute returns. If a pending or paused row is repriced or edited between the check and the CAS, the purchase can exceed the checked constraint.
Fix options: fold the constraint check into the purchase funnel so it runs against the CAS-returned row, or re-compare totals after the CAS and abort on a mismatch. Needs a regression test that mutates the row between the check and the CAS.
Activity
cristim commentedon Oct 6, 2026
Reproduced on main 68e0eaa by reading: handler_purchases.go ~337-346 checks constraints on GetExecutionByID recs, then RunPlannedPurchaseNow (~348) runs transitionApproveAndExecute (internal/purchase/approvals.go ~370) on the row returned by the CAS with no re-check. Same shape on the approve paths (~668, ~777, ~3086) and the approve-any/own checks (~872, ~886). Parked pending a design decision: (1) mechanism: a post-CAS validator callback into the funnel (changes the shared PurchaseManager interface in handler/types.go that #532 is reworking) vs re-comparing totals in the handler after the CAS; (2) rollback when the post-CAS check fails (revert to pending/paused vs mark failed with an audit note); (3) HTTP status (likely 403 via wrapConstraintDenied); (4) scope: run-now only vs all four callers (recommended: all four through the funnel, sequenced after #532).
IAmJSD commentedon Oct 16, 2026
Claiming: working on this
fix(purchase): re-check purchase constraints on the claimed row befor…