I signed up for the affiliate program and got TWO accounts — OTP verify TOCTOU + Gmail prefetch (PR #646 VI F3)

Aileen (29) Glasgow West End content creator @aileeneats applied to thMenu affiliate program; 5 minutes after the welcome email saw TWO Affiliate IDs (AILEEN22 + AILEEN76). Support busted 2 wrong theories (double submit, case-sensitive email). Workers ingest log: two verify requests 8ms apart, same token. (1) 15:14:23.142 IP 66.249.93.71 user-agent Google-Email-Verification — Gmail s safety prefetch service. (2) 15:14:23.150 IP 92.40.x AppleWebKit — Aileen s actual click. Verify endpoint: SELECT consumed=0 + validate + UPDATE SET consumed=1 + createAffiliate. Steps 1-3 race window: Request A SELECT consumed=0, UPDATE, create AILEEN22. Request B 8ms later SELECT consumed=0 (D1 eventual-consistency snapshot), UPDATE (idempotent no-op), create AILEEN76. Two affiliates. Deeper: verify endpoint was GET — RFC 9110 §9.2.1 says GET must be safe (no side effects beyond logging); Gmail / Outlook with Defender / Mimecast / Slack link unfurl ALL prefetch inbox URLs for safety scanning, triggering GET-with-state-change endpoints unintentionally. **PR #646 batch VI F3** two-layer fix: (1) atomic claim guard — UPDATE SET consumed=1 WHERE token=? AND consumed=0 AND expires_at>? + meta.changes detection; only one concurrent caller wins (meta.changes===1), the other gets meta.changes===0 → invalid_or_expired. (2) POST method enforcement — verify endpoint migrated GET→POST; email link renders a form, manual button-press POST triggers verification; email-scanning services don t POST, so prefetch path is closed. Aileen s AILEEN76 deleted, AILEEN22 kept; first commission landed 3 weeks later. Pattern: every single-use token verify (OTP, magic-link, password-reset, account-deletion-confirm) must use atomic UPDATE + WHERE race guard + POST method; SELECT-then-UPDATE + GET-with-state-change RFC violation combo guarantees silent double-spend in the presence of inbox URL prefetchers.

Related articles