Finding 4 of 85163d96 was fixed so that 'a well-formed code that arrives with anything else wrong is spent as well: one attempt per code'. The spend is guarded by b&&..., and b is null not only when the body is not JSON but also when body() rejects a parsed JSON object: an extra or missing key (Object.keys(v).length===keys.length at line 48), a Content-Type other than application/json, a Content-Length over 2048, or an empty body (line 44).

The route also answers 400 before token() runs when the URL carries a query string (line 217). In all of these the request is a failed exchange attempt that names a valid code, yet the code is untouched and a following correct exchange succeeds. This is scope item 2 of the request ('any exchange sequence that leaves a code usable after a failed attempt').

The disclosure in AUDIT_REQUEST section 2 covers only 'a body that does not parse'; a body that parses as JSON but carries one extra field is not covered.

Impact is limited: the attacker still needs the PKCE verifier to gain anything, so this is a rule-consistency gap, not a credential exposure.

Fix: decide the spend from the raw parsed JSON object rather than from body()'s shape check, e.g. parse once, extract code if it is a string matching OPAQUE, spend it, then apply the key-set check; and move the url.search check for the token route after that spend or treat it the same way.

Finding 5 of 85163d96 added revocation when 'a code presented again after it was used' arrives: the revoke runs only on the main path, after the consuming UPDATE returns zero rows. A second presentation of the same well-formed code with any other field wrong (client_id, redirect_uri, grant_type, or a verifier that fails OPAQUE) takes the 400 branch at line 131-135.

There the UPDATE at line 133 matches nothing (consumed_at is already set) and no revocation statement runs, so the grant minted on that code stays valid. The leak signal that RFC 6749 4.1.2 relies on (the code was seen a second time) is thus present but ignored on this branch. There is no attacker gain from this (an attacker who wants to keep the victim's grant alive would simply not replay), so it is a consistency gap between the two branches rather than an exposure.

Fix: in the 400 branch, after the spend UPDATE, run the same revocation statement when the spend changed no row (meta.changes===0), or restructure so that any well-formed code that is already consumed revokes its linked grant regardless of what else the body contains.

The fix for 85163d96 #5 (revoke the grant when a consumed code is presented again) lives at line 152, after the batch. The 400 branch added for finding #4 (lines 131-135) returns before that point. So a code that was already exchanged successfully, presented again together with any other field wrong (client_id, redirect_uri, grant_type, or a verifier that fails the format test), answers 400 and leaves the grant minted on that code valid.

The stated rule in AUDIT_REQUEST.md section 1 row 5 is 'a code presented again after it was used means it leaked: revoke the grant', and section 2 says any such second presentation ends the player's grant. The 400 path is a second presentation of a leaked code that does not.

Security impact is nil in practice (the party replaying chooses the malformed shape, and a legitimate second exchange is always well-formed, so it still revokes), but the behaviour is inconsistent with the rule the fix claims and with the disclosure.

Fix: in the 400 branch, when the UPDATE at line 133 changes no row (meta.changes===0) and the code is well-formed, run the same revoke statement as line 152 (token_hash<>'rejected'), or move the revoke into a helper called from both places.

Add a test: exchange OK, replay with client_id:'celestao' -> 400, then GET snapshot with the grant -> expect 401.

body() returns null not only when the bytes are not JSON but also when the parsed object has a key set different from the five expected keys (line 48), when Content-Type is not application/json, or when the body exceeds 2048 bytes (line 44-46). In token(), the new spend-on-400 at line 133 is guarded by b&&..., so in all of those cases the 400 is answered without consuming the code.

AUDIT_REQUEST.md section 1 row 4 states 'one attempt per code' and section 2 narrows the exception to 'a body that does not parse'. A JSON body such as {grant_type,client_id,redirect_uri,code,code_verifier,scope:'x'} does parse; it is answered 400 and the code can then be exchanged successfully.

Impact: none on secrecy (the verifier is never evaluated on this path, so it does not give extra verifier guesses), but it contradicts the one-attempt rule and the disclosure as written, and tests 85163d96 #4 only cover wrong values of the five keys, not a wrong key set or content type.

Fix: either widen the disclosure to 'a body that is not exactly the five expected JSON fields', or have body() return the parsed object with a separate shape flag so that a well-formed 'code' in any parsed JSON object is spent before the 400.

Private-repo path server/squeek-store.ts (commit 0cba662). AUDIT_REQUEST.md section 1 #4 says the 400 branch spends the code 'when the body parsed and code has the code format', and section 2 discloses only that 'a body that does not parse is answered 400 without touching any code'.

The 400-branch guard if(b&&...) relies on body() (line 48), which returns null not only for unparseable JSON but also for JSON that parsed correctly yet has a different key set (an extra key, or a missing key such as grant_type) or a non-application/json Content-Type. For those requests b is null, so a syntactically valid, live code in the body is left unconsumed and remains exchangeable afterwards.

This contradicts the stated 'one attempt per code' rule; it has no security impact (the code is still PKCE-bound and single-use on any well-formed attempt, and the response is a constant 400 so it is not an oracle), hence Info.

Fix: in body(), distinguish 'did not parse' from 'parsed but wrong keys' (e.g. return the parsed object and let token() validate the key set), then apply the same spend when the parsed object carries a code matching OPAQUE; alternatively narrow the disclosure to say that a body with an unexpected key set is also answered 400 without spending the code.

Private-repo path server/squeek-store.ts (commit 0cba662). The finding-5 fix revokes the grant only on the path after full body validation: the revoke UPDATE at line 152 runs when the consuming batch matched no row.

A replay of an already-exchanged code whose other fields are wrong (redirect_uri with a trailing character, client_id 'celestao', grant_type 'refresh_token', or a code_verifier that is not 43 base64url chars) is handled by the 400 branch at line 131-135: its UPDATE is scoped to consumed_at IS NULL, so it matches nothing, and no revoke statement runs.

The code was nevertheless 'presented again after it was used' (the condition the comment at line 151 and AUDIT_REQUEST.md section 1 #5 name as the leak signal), yet the grant stays live. Impact is nil for confidentiality: without the verifier the presenter gets no grant either way, and a well-formed replay still revokes; the gap is that the leak-signal revocation is bypassable by the party replaying, so the behaviour does not match the stated rule. Info.

Fix: in the 400 branch, when b carries a code matching OPAQUE, also run the same revoke UPDATE as line 152 (token_hash<>'rejected' already protects codes spent by mistake), or state in section 2 that only a well-formed replay revokes.

The 85163d96 #4 fix spends a well-formed code only when b is non-null. body() (lines 43-49) returns null not only for unparseable JSON but also for a JSON object that parsed fine and carries a valid code when: the object has a sixth key (Object.keys(v).length===keys.length fails), any of the five keys is missing, the Content-Type is not application/json, or Content-Length/body exceeds 2048 bytes.

In all of those cases the 400 is answered without touching the code, so the same code is still exchangeable afterwards. This contradicts the in-code rule on line 132 ('A well-formed code that arrives with anything else wrong is spent as well: one attempt per code') and is wider than the section 2 disclosure, which only exempts 'a body that does not parse'.

Boundary seam: the spend is keyed on the parser's shape check rather than on the presence of a code-format value. Impact is nil for GOLD or identity: no verifier attempt is gained (PKCE still binds the code), the per-client budget is still charged, and the normal path burns the code on the first real attempt. It is reported because the request asks for 'any exchange sequence that leaves a code usable after a failed attempt' and this one does, deterministically.

The reuse detector finds the grant to revoke through the squeek_auth_codes row of the replayed code. That row has expires_at = issued_at + SQUEEK_CODE_TTL_MS (60 s, lines 20 and 123) and pruneSqueekAuth (line 245) deletes rows with expires_at<=now. The Worker runs it from the housekeeping branch of scheduled (worker/app.ts line 270), which is the */15 * * * * cron (wrangler.jsonc line 78; the * * * * * tick returns early at line 253 and never prunes).

A grant issued on that code lives SQUEEK_TOKEN_TTL_MS = 60 min.

Numbers: code minted at t0, exchanged at t0+2 s, code row expires at t0+60 s, deleted at the first quarter-hour tick after that, i.e. between t0+60 s and t0+16 min depending on where t0 falls in the quarter hour; from then until t0+60 min a replay hits rows[0].results.length===0 (unknown code), the subquery returns NULL, token_hash=NULL matches nothing and the grant survives.

The protection therefore covers between about 1 and 16 of the 60 minutes in which a leaked code could signal a leaked grant, which is the RFC 6749 4.1.2 purpose the fix cites; the median case is roughly 8 minutes.

Section 2 discloses the pruning qualitatively ('after which a replay revokes nothing') but not that the covered window is minutes rather than the grant lifetime; the request asks explicitly for cases that 'fail to revoke on reuse', so the quantified gap is recorded here. Boundary x invariant seam: the invariant 'a reused code revokes its grant' is enforced through a row whose lifetime (60 s plus prune lag) is shorter than the grant it is meant to protect (3600 s).

No GOLD, data or identity exposure follows from the gap; a surviving grant is read-only.

The 85163d96 #4 fix spends a well-formed code only when b is non-null. body() (lines 43-48) returns null not only for bytes that are not JSON but also for a JSON object that parsed and carries a valid code when: the key set differs from the five expected keys (an extra key, or a missing one), the Content-Type is not application/json, or the body exceeds 2048 bytes. The token route also answers 400 at line 217 before token() runs when the URL carries a query string.

In all of these cases the request is a failed exchange attempt naming a live code, the per-client budget is charged, but the code row is untouched and a following correct exchange succeeds. This contradicts the comment on line 132 ('one attempt per code') and is wider than the AUDIT_REQUEST.md section 2 disclosure, which exempts only 'a body that does not parse'.

Impact is nil for GOLD or identity: the verifier is never evaluated on this path, so no extra PKCE guess is gained, the response is a constant 400, and the first well-formed attempt still burns the code. It is reported because scope item 2 asks for any exchange sequence that leaves a code usable after a failed attempt. Reproduced in a harness built from the package (handleSqueek + the real migrations; withheld ledger modules stubbed).

Merged from four specialists (economics, flow, permissions, math), who all describe this one seam.

Fix: parse once and decide the spend from the raw parsed object (if it is an object whose code is a string matching OPAQUE, run the spend UPDATE), then apply the key-set and Content-Type checks; move the url.search check for the token route after that spend or treat it the same way. Alternatively narrow the comment and the section 2 disclosure to say exactly which 400s spend (only a body that parses as exactly the five expected JSON fields).

The 85163d96 #5 fix revokes the grant only on the main path: after the consuming batch, when the UPDATE at line 141 matched no row. A second presentation of an already-exchanged code with any other field wrong (client_id, redirect_uri, grant_type, or a code_verifier that fails the 43-character format) takes the 400 branch at lines 131-135.

Its spend UPDATE (line 133) is scoped to consumed_at IS NULL, so it matches nothing, no revocation statement runs, and the grant minted on that code stays valid. The code was nevertheless 'presented again after it was used', which is the leak signal the comment on line 151 and AUDIT_REQUEST.md section 1 row 5 name, and section 2 says any such second presentation ends the player's grant.

Security impact is nil: the party replaying chooses the malformed shape and gains nothing by it (without the verifier no grant is issued either way), and a legitimate or attacker-run well-formed replay still revokes. It is a consistency gap between the two branches and the stated rule. Reproduced in a harness built from the package.

Merged from three specialists (economics, flow, permissions).

Fix: in the 400 branch, when b carries a code matching OPAQUE and the spend UPDATE changed no row (meta.changes===0), run the same revoke UPDATE as line 152 (its token_hash<>'rejected' clause already protects codes spent by mistake); or move the revoke into a helper called from both places.

Add a test: exchange OK, replay with client_id:'celestao' -> 400, then GET snapshot with the grant -> expect 401.

The reuse detector at line 152 finds the grant to revoke through the squeek_auth_codes row of the replayed code (subquery on code_hash). That row has expires_at = issued_at + SQUEEK_CODE_TTL_MS (60 s, lines 20 and 123) and pruneSqueekAuth deletes rows with expires_at<=now (line 245). The Worker calls it from the housekeeping branch of scheduled (worker/app.ts line 270), which is the */15 * * * * cron (wrangler.jsonc line 78; the minute tick returns early at line 251).

The grant issued on that code lives SQUEEK_TOKEN_TTL_MS = 60 min.

Timeline: code minted at t0 and exchanged; the code row expires at t0+60 s and is deleted at the first quarter-hour tick after that, i.e. between t0+60 s and t0+16 min depending on where t0 falls in the quarter hour. From then until t0+60 min a replay finds no row (rows[0].results.length===0), the subquery returns NULL, token_hash=NULL matches nothing, and the grant survives.

The invariant 'a reused code revokes its grant' is therefore enforced through a row whose lifetime is shorter than the grant it protects: the cover is about 1 to 16 of the 60 minutes (roughly 8 in the median case). Section 2 discloses the pruning qualitatively ('after which a replay revokes nothing') but not that the covered window is minutes rather than the grant lifetime, and scope item 2 asks explicitly for cases that fail to revoke on reuse.

No GOLD, data or identity exposure follows: a surviving grant is read-only and the normal single-use and PKCE checks are unaffected. Reproduced in a harness built from the package with a controllable clock. From the math specialist; no duplicate.

Fix preserving the design: make the code row outlive the grant it produced, for example in the consuming UPDATE at line 141 also set expires_at=MAX(expires_at,?1+SQUEEK_TOKEN_TTL_MS) when a grant is issued, or prune consumed rows only when token_hash='rejected' OR expires_at<=?1-SQUEEK_TOKEN_TTL_MS; or store code_hash on squeek_tokens and revoke by that column so the revoke no longer depends on the code row.

If the owner keeps the trade-off, state the 1-16 minute window in section 2 and in the game specification.