Affiliate Cookie Poisoning: Stealing Attribution and Commissions

Affiliate Cookie Poisoning: Stealing Attribution and Commissions

Affiliate systems trust a cookie more than they should. You click ?ref=PARTNER42, the site sets aff=PARTNER42 for thirty days, and checkout stamps that partner on the order. If anything lets you rewrite aff without a fresh valid click, commissions move.

Cookie poisoning here is not XSS. It is trusting a client-controlled attribution token at payment time.

Follow the token

Click your own affiliate link (or a documented tracking URL in a public program). Record:

• Set-Cookie name, flags, domain, path, lifetime
• Whether a server-side click event is stored before the cookie is honored
• Hidden form fields like affiliateId duplicated into checkout POST bodies

If checkout reads the hidden field or a raw cookie without tying it to a prior signed click, you can swap values.

Try setting aff=VICTIM_PARTNER manually in DevTools before purchasing with a second account you own. If the order dashboard credits the victim partner—or better, your attacker affiliate ID without visiting their link—you have attribution fraud.

Local storage and first-party postMessage helpers sometimes mirror the same ID. Clear cookies but leave localStorage.affId and retest. Engineers patch Set-Cookie and forget the duplicate store.

Poisoning without XSS

Common paths:

• Open redirect or host-header issues that set affiliate cookies for arbitrary IDs
• POST /affiliate/claim that accepts any partnerId
• Subdomain that shares the parent cookie scope and lets you plant aff
• Race: last-click wins with no purchase-window binding, so a 1x1 "pixel" visit late in checkout rewrites credit

Last-click abuse can be in-scope when the program runs an affiliate channel. Show you changed credit between two controlled partners, not that you stole from a stranger.

Cross-site image or script includes on marketing microsites are classic planters. If track.example.com sets a parent-domain cookie from any Referer, an attacker's page can force attribution before the victim even sees the shop.

Mobile deep links (app://ref/PARTNER) that write the same cookie deserve a parity check against web. One platform locked, the other wide open, is still a valid finding.

Receipts triage wants

Two affiliate accounts. Partner A should have earned the sale; you force Partner B. Provide order ID, both partner IDs, cookie values, and the request that overwrote attribution. Revenue share percentages help severity.

If the cookie is HttpOnly and the only writer is a signed redirect from the affiliate service, say so—you may only have last-click policy abuse, which some companies accept. The clear bug is accepting an unsigned partner ID from the client at order create.

Mention whether the overwrite works after payment intent creation or only before. Locking attribution earlier shrinks the window; say where the window still open was.

Hardening notes

Bind attribution to a server-side click ID with signature and expiry, ignore raw partner slugs on checkout, prefer first-party server sessions over long-lived writable cookies, and lock attribution at payment intent creation. Audit subdomains for shared cookie scope.

Affiliate bugs get dismissed when they sound like "marketing philosophy." They stick when you move money between two test partners with one edited cookie.