reCAPTCHA / Coupon / Captcha Reuse as Business-Logic Attack Surface

Many business-logic bugs are not parser bugs at all. They come from weak binding between a proof token and the exact action, user, or cart it was supposed to protect.

Why It Matters

• A token generated once and consumed many times (or shared across sessions) defeats the control it was meant to enforce.

Vulnerable Pattern

• Challenge tokens, coupon codes, captchas, and discount flows reused across sessions or insufficiently bound to identities/state.

Exploit Flow

1. Replay the same token against another account, cart, or workflow step.
2. Test whether generation and validation happen under the same identifier, or whether one is global and reusable.

Variations

• g-recaptcha-response replay, coupon reuse, stale cart IDs, or captchas generated once and consumed many times.

Common Blockers

• Server correctly binds the token to one session and one action — but check this early.

PoC Sketch

# submit the same g-recaptcha-response or coupon code twice
# with different accounts/carts; compare whether the server binds it to the right session

Good Situations To Use It

• A flow relies on a proof token (captcha/coupon/challenge).
• Binding to user/action/cart looks weak.
• Replaying is cheap to test.

Sources

• sthack2026/web/what_a_hell
• ehaxctf2026/web/modernshop