sec(api): approvePurchaseViaSession leaks execution existence and status before authorization #172

Found while adversarially reviewing PR LeanerCloud/cloud-commitments-cli#1744. Pre-existing on main, outside that diff, so filed rather than folded in.

approvePurchaseViaSession returns a 409 carrying status=<X> before calling authorizeSessionApprove. A session with no approve rights can therefore probe both the existence and the current status of an execution whose UUID it already holds.

Low severity, and deliberately labelled as such: it requires knowing the UUID, and it discloses status rather than content. But it is an authorization check running after a response that varies on protected state, which is the shape worth not having.

For contrast, a sibling path was checked and is fine: runPlannedPurchase validates UUID syntax before authorizing, which discloses nothing — a malformed UUID is malformed regardless of what exists. The distinction is whether the pre-auth response varies with protected state. It does in the 409 case and does not in the syntax case.

Suggested fix

Authorize before any response that depends on the execution row. If a distinct 409 is genuinely useful to legitimate callers, emit it only after the approve check passes; unauthorized callers should get the same response whether or not the execution exists.

Verification

Two directions, both required:

• An unauthorized session probing a real execution UUID and a non-existent one must get responses that are indistinguishable — same status, same body.
• An authorized session must still receive the informative 409, or the fix has traded a small leak for a real usability regression.

A test asserting only the first direction would pass against a handler that refuses everyone.

Related

• PR fix(test): make grantAdmin model the principal instead of stubbing the authorization decision cloud-commitments-cli#1744 / fix(test): grantAdmin authorization-decision stub — remainder after #1744 (pair pinning, .Maybe() per-handler, scoped-account conversion) cloud-commitments-cli#1596 — the review that surfaced this.
• sec(auth): account scoping fails OPEN when a user's groups cannot be resolved (unrestricted access to all accounts) cloud-commitments-cli#1748 — separate and more serious: account scoping fails open when a group cannot be resolved. Unrelated mechanism, same area.

Findings from the 2026-09-02 codebase audit

Added by an automated audit of 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd (tip of origin/main). Each item below was reported by one reviewer and independently confirmed by a second that did not write it. Full report: docs/audits/codebase-audit-2026-09-02.md.

A01-017 (low)

The same shape on two more routes, and one auth level lower, from finding A01-017. This issue covers approvePurchaseViaSession; the other AuthPublic money routes leak the same way to a caller with no token and no session at all. revokeViaEmailToken (internal/api/handler_purchases.go:1248-1260) returns 404 "execution not found", 409 "still pending" or 409 "cannot be revoked (status=)" before tryRevokeViaSession or authorizeApprovalAction run; cancelPurchase (:1029-1035) 404s pre-auth; and loadApproveExecution (:523-537) returns 404 and orphan-detail 409s before either auth branch. All three are registered as AuthPublic at router.go:163-172. The verification bar stated here (a real and a non-existent UUID must be indistinguishable) should apply to all four handlers, since fixing one leaves the oracle intact on the others.