CVE-2026-34226

What it actually does

Happy DOM versions prior to 20.8.9 can apply the wrong cookie scope when code calls fetch(..., { credentials: "include" }). Instead of attaching cookies that belong to the destination request URL, the implementation may attach cookies associated with the current window.location origin. In server-side rendering, testing, crawling, automation, or application code that uses Happy DOM as a browser-like runtime, this can disclose origin-specific cookies to an unintended remote endpoint. The vulnerability is a confidentiality issue only: it does not directly provide code execution, privilege escalation, or service disruption.

Why it matters to the business

Applications or tooling that use vulnerable Happy DOM versions may unintentionally send sensitive cookies, such as session identifiers or authentication-related tokens, to third-party or attacker-controlled URLs. This can lead to account compromise, exposure of internal test or automation credentials, and leakage of secrets during automated workflows. The CVSS confidentiality impact is high, but current exploitation signals are low: EPSS is 0.00458, it is not listed in CISA KEV, and no mature public exploit is indicated. Risk is highest where Happy DOM processes real user cookies, production-like credentials, or untrusted URLs.

How an attack unfolds

An attacker needs a vulnerable application or automation workflow that uses Happy DOM and performs credentialed fetch requests. The attacker first influences the code, data, URL, test fixture, HTML content, or plugin behavior so that Happy DOM’s current page origin has sensitive cookies set. They then cause the runtime to execute fetch() with credentials: "include" to a destination they control or can observe. Due to the flawed cookie attachment logic, Happy DOM may send cookies from the current window.location origin rather than cookies scoped to the request target. The attacker collects the leaked Cookie header at the receiving endpoint and attempts to reuse any exposed session or authentication material before it expires or is revoked.

How to fix it

Upgrade Happy DOM to version 20.8.9 or later wherever it is used. Because this is a dependency-level flaw, update direct package manifests and lockfiles, then rebuild and redeploy affected applications, CI images, test runners, SSR services, crawlers, and automation containers. If immediate upgrade is not possible, avoid using fetch(..., { credentials: "include" }) in Happy DOM contexts that may contact untrusted or cross-origin URLs, prevent untrusted input from controlling fetch destinations, avoid storing real production cookies in Happy DOM-based automation, and rotate any cookies or tokens that may have been exposed. Enforce dependency scanning in CI so versions prior to 20.8.9 are blocked.

How to confirm the fix worked

Confirm that all resolved Happy DOM package versions are 20.8.9 or later by inspecting package lockfiles and installed dependency trees, for example with npm ls happy-dom, yarn why happy-dom, or pnpm why happy-dom depending on the package manager. Add or run a regression test that sets a cookie for one origin, performs fetch(..., { credentials: "include" }) to a different origin, and verifies that the current-origin cookie is not sent to the destination. Validate deployed containers and build artifacts, not only source manifests, because vulnerable transitive copies may remain in lockfiles or cached images.

Typical attack path

1. Identify an application, test framework, SSR pipeline, scraper, bot, or automation process using Happy DOM before version 20.8.9.
2. Find a path to influence page location, loaded content, request destination, or code that performs fetch(..., { credentials: "include" }).
3. Ensure sensitive cookies are present for the current Happy DOM window.location origin, such as session, auth, or application cookies.
4. Trigger a credentialed fetch request from that context to an attacker-controlled or observable destination URL.
5. Capture the outbound HTTP request and inspect the Cookie header for cookies that should not have been sent to that destination.
6. Attempt to reuse leaked cookies or authentication material, or use the leak to pivot into related accounts or services.

How to detect it

To determine whether exploitation or accidental exposure already occurred, review outbound proxy, firewall, egress gateway, web server, API gateway, and application logs for Happy DOM-based processes making cross-origin HTTP requests that include Cookie headers. Focus on requests generated by CI runners, test jobs, SSR services, scrapers, crawlers, bots, and automation containers using vulnerable Happy DOM versions. Look for fetch requests with credentials included where the destination host differs from the origin being simulated by the application. If available, inspect application debug logs, HTTP client instrumentation, request-capture logs, and packet captures for Cookie headers sent to unexpected external domains. Also review dependency telemetry and build logs to identify the time window during which versions prior to 20.8.9 were deployed. There are no widely reported threat actor-specific indicators for this vulnerability; detection is primarily behavioral and environment-specific.

• happy-dom@20.8.8
• happy-dom@20.8.7
• happy-dom@20.8.6
• happy-dom@20.8.5
• happy-dom@20.8.4
• happy-dom@20.8.3
• happy-dom@20.8.2
• happy-dom@20.8.1
• happy-dom@20.8.0
• "happy-dom": "<20.8.9"
• "happy-dom":"<20.8.9"
• fetch(
• credentials: "include"
• credentials:'include'
• credentials: `include`
• Cookie:

What your security team should do

• Inventory all projects, CI jobs, containers, test harnesses, SSR services, bots, and automation workflows that include the happy-dom package.
• Prioritize upgrades to Happy DOM 20.8.9 or later for systems that process real credentials, production-like cookies, customer sessions, or untrusted URLs.
• Search dependency manifests and lockfiles for Happy DOM versions earlier than 20.8.9 and open remediation tickets for each affected repository or image.
• Review code for fetch calls using credentials: "include" inside Happy DOM contexts, especially when the request URL can be influenced externally or points cross-origin.
• Rotate potentially exposed session cookies, API tokens, or automation credentials if logs show credentialed requests from Happy DOM workflows to untrusted destinations.
• Add automated dependency policy checks that fail builds when happy-dom resolves to a vulnerable version.
• Monitor outbound HTTP logs from automation and SSR environments for unexpected Cookie headers sent to third-party domains.