# Happy DOM's fetch credentials include uses page-origin cookies instead of target-origin cookies

happy-dom's fetch with credentials:include selects cookies by page origin instead of request target, leaking origin A cookies to origin B.

- Payout: Research
- Severity: high
- Program: happy-dom
- Found by: r74tech
- Disclosed: 2026-03-29
- CVE: CVE-2026-34226
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-w4gp-fjgq-3q4g
- Library page: http://bugbountylibrary.com/r/ghsa%3AGHSA-w4gp-fjgq-3q4g
- Tags: area:web domain:oss domain:web impact:data-leak kind:research platform:ghsa sev:high tech:nodejs technique:source-review vuln:cors vuln:info-disclosure

**Target:** happy-dom fetch implementation (FetchRequestHeaderUtility.getRequestHeaders)
**Root cause:** getRequestHeaders() builds originURL from options.window.location.href and passes it to cookieContainer.getCookies() instead of the request URL, so cookie selection uses the page origin rather than the destination origin.
**Steps:**
1. Set page_cookie=PAGE_ONLY on page origin a.127.0.0.1.nip.io
2. Set api_cookie=API_ONLY on target origin b.127.0.0.1.nip.io
3. From the page, call `page.mainFrame.window.fetch('http://b.127.0.0.1.nip.io:<port>/data', { credentials: 'include' })`
4. Observe the target server's Cookie header: it contains `page_cookie=PAGE_ONLY` and omits `api_cookie=API_ONLY`
**How found:** Code review of FetchRequestHeaderUtility.ts: noticed getCookies() was called with originURL derived from window.location.href rather than the request URL, contradicting fetch spec cookie scoping.
**Exploitation:** Any app using happy-dom's browser-like fetch in authenticated flows (SSR, tests, proxy-like scenarios) sends the page origin's cookies to a cross-origin destination, disclosing session cookies to the target host.
**Insight:** When auditing DOM/browser emulators, check that cookie jar lookups key off the request URL, not window.location — emulators often conflate page origin with request origin in CORS and credentials handling.