Discount Stacking

What is Discount Stacking#

Discount stacking is a business-logic vulnerability in which a single-use coupon, referral bonus, or promotional credit is redeemed more times than the application intends. The canonical instance is a Time-Of-Check / Time-Of-Use (TOCTOU) race condition on a /apply-coupon endpoint, but the same business outcome can be reached via sequential code reuse, cross-account replay, or by stacking incompatible promotion types in a single order. The vulnerability class is mapped to CWE-841 (Improper Enforcement of Behavioral Workflow) and to OWASP A04:2021 — Insecure Design, because the flaw is not a missing input filter but a missing concurrency or policy control on a state transition.

The CVSS v3.1 base score is 6.5 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. Confidentiality and availability are unaffected, but integrity is high because price, order total, and revenue ledgers are directly corrupted by the attacker. In practice the business impact frequently exceeds the CVSS rating: a single attacker running Burp Suite Turbo Intruder can drain a six-figure promotional budget in seconds, and the loss scales linearly with automation rather than with attacker skill.

It is important to distinguish discount stacking from generic price manipulation. Price manipulation modifies a client-supplied total ({"price": -10}) and is fixed by recomputing the total server-side. Discount stacking, by contrast, sends the correct coupon code to the correct endpoint with the correct user identity — the server simply fails to enforce that one code equals one redemption when N concurrent requests collide. The two often coexist, but the controls are different: server-side recomputation does not protect against a race condition on the coupon table itself.

Mechanism#

The vulnerable flow contains a measurable gap between reading coupon state and writing it. During that window, parallel requests all observe used = false, all proceed, and all commit a redemption.

The exploit reduces to four ordered steps that any tester can reproduce:

1. Identify a discount surface — coupon field, referral link, loyalty redemption, gift card application.
2. Capture one valid POST /apply-coupon request in a proxy and replay it once in Repeater to confirm the baseline behaviour.
3. Send 20 to 50 copies of the same request through HTTP/2 single-packet attack so all bytes arrive in one TCP segment.
4. Inspect the response set: multiple 200 OK for a single-use code, a discount sum exceeding the cart total, or a duplicated discount_id in the order line items confirms the race.

A representative exploit request looks like this:

POST /checkout/apply-promo HTTP/2
Host: shop.example.com
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
 
{"promo_code": "FIRST50", "order_id": "ord_88abc"}

Twenty copies of this request, gated on the last byte and released simultaneously, will apply FIRST50 twenty times on a vulnerable server. The race window is typically 1 to 50 milliseconds on a CDN-fronted application and considerably wider on a monolithic backend under load.

Attack Variants#

The TOCTOU race is the canonical case, but the same financial outcome is reachable through several non-concurrent paths that defenders often miss.

The cross-account and referral variants are particularly hard to detect because each individual request is well-formed and authenticated as a different legitimate user. Detection here requires graph-level analysis (cycle detection in the referral graph, device-fingerprint correlation across accounts) rather than per-request validation.

Real-World Examples#

Instacart — HackerOne #157996#

Researcher Jack Cable (@cablej) reported in 2016 that Instacart's coupon redemption endpoint allowed the same promo code to be redeemed twice via concurrent requests. The backend checked redemption status and then applied the credit, but the update was not atomic. Instacart awarded a $200 bounty. After the initial patch, Cable found a bypass that redeemed two different codes simultaneously, still stacking the savings — a reminder that fixing the surface request without fixing the underlying transaction model leaves the class of bug intact.

Stripe — HackerOne #1849626#

In January 2023, researcher @ian discovered that Stripe's fee-discount acceptance endpoint was vulnerable to a race condition. By calling the discount acceptance endpoint 30 times in parallel via Burp Suite Turbo Intruder, he accumulated $600,000 in fee-free transaction volume from a single $20,000 promotional offer. Stripe's loss per abuse — about $600 (3 percent of $20K) — was far smaller than the headline number, but the report illustrates how a few seconds of automation can multiply a finite promotion by 30x. Stripe paid $5,000 and resolved the issue with server-side idempotency on the discount acceptance call.

Stripe — HackerOne #1717650#

A separate Stripe report from September 2022 showed that promotion codes carrying explicit redemption limits (for example limit=1) could be redeemed beyond their cap via a race condition on Stripe Checkout links. The exploit required no special tooling — only a browser opening the same checkout link in multiple tabs concurrently. Stripe paid $250 and fixed the issue with atomic redemption tracking. The low bounty relative to #1849626 reflects the smaller direct loss, but the root cause and class are identical.

WooCommerce Smart Coupons — CVE-2020-36841#

Not every discount-stacking incident is a race condition. CVE-2020-36841 in WooCommerce Smart Coupons (versions ≤4.6.0) allowed unauthenticated users to send themselves gift certificates of arbitrary value by abusing an authorization bypass in the coupon creation logic. The financial impact is functionally equivalent to a successful stacking attack — attackers fabricated discount value out of nothing — but the root cause is missing access control on the create endpoint rather than a TOCTOU window. Patched in version 4.6.5. The advisory is tracked at GHSA-x279-24jv-7gr3.

Detection#

Manual Testing#

Manual testing for discount stacking is fast once the discount surfaces are mapped. The procedure is identical for coupons, referrals, gift cards, and loyalty redemptions.

1. Capture one valid POST /apply-coupon request in Burp Proxy.
2. Replay it three to five times in Repeater. If the same single-use code applies on the second send, you have non-race code reuse — no further tooling needed.
3. Send the request to Burp Suite Turbo Intruder and use the PortSwigger race-single-packet-attack.py template. Set 20 parallel requests gated on the same word. Open the gate; all twenty bytes leave together over a single HTTP/2 connection.
4. After the batch, read the cart total, the account credit balance, and the coupon current_uses column. Multiple 200 OK responses, a discount sum greater than the cart, or current_uses lower than the request count all confirm the race.
5. Repeat the exercise with mutated inputs: quantity: -1, discount_percent: 150, two different valid codes in parallel, the same code from two accounts on the same device.

The Turbo Intruder template that drives the exploit is short:

def queueRequests(target, wordlists):
    engine = RequestEngine(endpoint=target.endpoint,
                           concurrentConnections=1,
                           engine=Engine.BURP2)
    for i in range(20):
        engine.queue(target.req, gate='race1')
    engine.openGate('race1')
 
def handleResponse(req, interesting):
    table.add(req)

Automated Detection#

Programmatic detection focuses on signals that are reliable across stacks: response distribution, side-effect divergence, and database invariants.

Open-source tools that automate this surface include the Burp Race the Web extension, Turbo Intruder with the single-packet template, ffuf with high concurrency (-t 30) for sequential probing, and custom Python asyncio plus httpx scripts for precise timing. Caido offers a similar replay-group capability for teams that have moved away from Burp.

BreachVex detects discount stacking through dedicated race-condition probing on coupon, promo, referral, and gift-card endpoints discovered during attack-surface mapping. The scanner replays each candidate request concurrently, compares the response distribution against a single-shot baseline, and emits a CONFIRMED finding only when the side-effect divergence (multiple successful redemptions, exceeded max_uses, or duplicated discount line items) is observed, with every confirmed finding backed by a dual-judge proof flow.

Prevention#

The two controls below work together. The atomic transaction prevents the race on the coupon row itself, and the idempotency key prevents the same logical operation from being attempted twice in any other guise.

Atomic Database Transactions#

The vulnerable pattern reads coupon state outside a lock and writes it later:

# VULNERABLE — TOCTOU window between check and update
async def apply_coupon(order_id: str, code: str, user_id: str) -> dict:
    coupon = await db.fetch_one("SELECT * FROM coupons WHERE code=:code AND used=false", {"code": code})
    if not coupon:
        raise ValueError("Invalid coupon")
    # ...network round-trip, ORM overhead, no lock held...
    await db.execute("UPDATE coupons SET used=true WHERE id=:id", {"id": coupon.id})
    await db.execute("INSERT INTO redemptions (coupon_id, user_id, order_id) VALUES (:c, :u, :o)",
                     {"c": coupon.id, "u": user_id, "o": order_id})
    return {"discount": float(coupon.discount_amount)}

The fixed pattern wraps the read and the write in a single transaction with a row-level lock, so concurrent transactions block on SELECT ... FOR UPDATE rather than racing past it:

# FIXED — SELECT FOR UPDATE holds a row lock for the duration of the tx
from sqlalchemy import text
 
async def apply_coupon(order_id: str, code: str, user_id: str) -> dict:
    async with get_db() as db:
        async with db.begin():
            coupon = await db.execute(text("""
                SELECT id, discount_amount, max_uses, current_uses
                FROM coupons
                WHERE code = :code
                  AND is_active = true
                  AND (expires_at IS NULL OR expires_at > now())
                FOR UPDATE NOWAIT
            """), {"code": code}).fetchone()
 
            if not coupon:
                raise ValueError("Coupon not found or expired")
            if coupon.current_uses >= coupon.max_uses:
                raise ValueError("Coupon exhausted")
 
            existing = await db.execute(text(
                "SELECT 1 FROM coupon_redemptions WHERE coupon_id=:cid AND user_id=:uid"
            ), {"cid": coupon.id, "uid": user_id}).fetchone()
            if existing:
                raise ValueError("Already redeemed by this user")
 
            await db.execute(text(
                "UPDATE coupons SET current_uses = current_uses + 1 WHERE id = :cid"
            ), {"cid": coupon.id})
            await db.execute(text("""
                INSERT INTO coupon_redemptions (coupon_id, user_id, order_id)
                VALUES (:cid, :uid, :oid)
            """), {"cid": coupon.id, "uid": user_id, "oid": order_id})
 
            return {"discount_amount": float(coupon.discount_amount)}

A UNIQUE(coupon_id, user_id) constraint on coupon_redemptions provides a database-enforced safety net: even if a concurrency bug slips past the application code, the second INSERT fails with a constraint violation rather than silently double-redeeming.

Idempotency Keys#

For higher-value flows — payment-bearing checkouts, fee discount acceptance — pair the atomic transaction with a server-side idempotency key derived from the operation, not from a client-supplied header. The example below uses Redis SET NX to acquire a short-lived lock per (user, code, order) and a Knex transaction with forUpdate to perform the redemption atomically:

const Redis = require('ioredis');
const client = new Redis();
 
async function applyCoupon(req, res) {
  const { code, orderId } = req.body;
  const userId = req.user.id;
 
  // Idempotency key: one application per (user, code, order)
  const idemKey = `coupon:${userId}:${code}:${orderId}`;
  const acquired = await client.set(idemKey, '1', 'NX', 'EX', 300); // 5 min TTL
 
  if (!acquired) {
    return res.status(409).json({ error: 'Coupon application already in progress' });
  }
 
  try {
    const result = await db.transaction(async (trx) => {
      const coupon = await trx('coupons')
        .where({ code, is_active: true })
        .forUpdate()
        .first();
 
      if (!coupon || coupon.current_uses >= coupon.max_uses) {
        throw new Error('Coupon invalid or exhausted');
      }
 
      await trx('coupons').where({ id: coupon.id }).increment('current_uses', 1);
      await trx('coupon_redemptions').insert({
        coupon_id: coupon.id, user_id: userId, order_id: orderId,
      });
 
      return { discount: coupon.discount_amount };
    });
 
    return res.json(result);
  } finally {
    await client.del(idemKey);
  }
}

Two further controls round out a defensible implementation. First, recompute the order total server-side on every checkout submission and clamp the result with max(final_price, 0) so that no combination of discounts can produce a negative charge. Second, never burn coupons in an asynchronous worker — the window between commit and burn is the exact bug exploited in the Stripe and Instacart reports above.

Related Topics#

• Limit Override — Same TOCTOU race condition pattern applied to per-user quotas.
• Workflow Step Bypass — Skip payment after applying stacked discounts.
• Currency Rounding Abuse — Compounding rounding errors with discount math.
• Business Logic Flaws (overview) — Pillar page with all 6 variants.

Resources#

• Race Conditions — PortSwigger Web Security Academy
• Stripe Fee Discounts Race — HackerOne #1849626
• Instacart Coupon Race — HackerOne #157996
• OWASP A04:2021 — Insecure Design