# CVE-2023-5480: Chrome new XSS Vector

Chrome's Payment Request API fetched payment manifests from file-download endpoints ignoring Content-Disposition, letting a JIT-installed Service Worker from an uploaded manifest achieve XSS on the origin.

- Payout: $16,000
- Severity: high
- Program: Google
- Credited: Vsevolod Kokorin (slonser_)
- Disclosed: 2024-01-25
- CVE: CVE-2023-5480
- Write-up quality: 8/10
- Original: https://blog.slonser.info/posts/cve-2023-5480/
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-slonser-info-posts-cve-2023-5480
- Tags: domain:browser impact:data-leak impact:integrity kind:bounty platform:blog sev:high tech:chromium technique:chained technique:source-review vuln:misconfiguration vuln:xss

**Target:** Chromium Payment Request API / Payment Method Manifest handling
**Root cause:** A 2020 spec-compliance change made Chromium fetch the payment method manifest directly from the payment method URL body even when Content-Disposition: attachment is set, so attacker-uploaded files on download endpoints are parsed as manifests. The manifest's serviceworker field triggers JIT installation of an attacker-controlled Service Worker on the target origin.
**Steps:**
1. Upload `payment-manifest.js` (JSON with `default_applications` and `supported_origins`) to a target download endpoint that serves files with `Content-Disposition: attachment` but preserves MIME type.
2. Upload `manifest.js` (Web App Manifest) referencing `serviceworker.src` pointing to an attacker JS file within the download scope.
3. Upload `sw-slonser.js` that registers a `fetch` handler returning `new Response(new Blob(["<script>alert('pwned')</script>"],{type:"text/html"}))`.
4. Host `attack.html` on attacker domain calling `new PaymentRequest([{supportedMethods: BASE+'/payment-manifest.js'}], {...}).show()`.
5. On rejection, redirect victim to `${BASE}/C4T BuT S4D`; the JIT-installed Service Worker intercepts and returns attacker HTML, yielding XSS on the target origin.
**How found:** Author read Chromium source and noticed the manifest fetch logic changed in March 2020 to also accept the response body directly per spec, without accounting for Content-Disposition: attachment on download endpoints; realized the body would be parsed as a manifest and the serviceworker field would install a worker.
**Exploitation:** Victim visits attacker page; PaymentRequest fetches the uploaded manifest from the target's download endpoint, JIT-installs the attacker Service Worker scoped to the download path, and after redirect the worker serves attacker HTML/JS on the target origin. On S3 buckets the worker can exfiltrate every file the user opens to an attacker server.
**Escalation:** Chaining JIT Service Worker installation with any file-upload/download endpoint (GitLab artifacts, S3 buckets) turns a benign download feature into stored XSS and data exfiltration across the origin.
**Insight:** When a spec change makes a browser consume a response body it previously ignored, look for endpoints that serve attacker-controlled bytes with attachment disposition but preserved MIME type — those become parser inputs for privileged features like Payment manifests and JIT Service Workers.