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
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.
Found while adversarially reviewing PR LeanerCloud/cloud-commitments-cli#1744. Pre-existing on
main, outside that diff, so filed rather than folded in.approvePurchaseViaSessionreturns a 409 carryingstatus=<X>before callingauthorizeSessionApprove. 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:
runPlannedPurchasevalidates 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:
A test asserting only the first direction would pass against a handler that refuses everyone.
Related
Findings from the 2026-09-02 codebase audit
Added by an automated audit of
3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd(tip oforigin/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=)" beforetryRevokeViaSessionorauthorizeApprovalActionrun;cancelPurchase(:1029-1035) 404s pre-auth; andloadApproveExecution(: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.