Happy DOM EUVD-2026-112468

Requires that the application run happy-dom < 20.14.6 as a server-side rendering or prerendering engine that performs cookie handling via CookieContainer, AND that within the same Window/cookie container it first issues a request to an attacker-controlled origin and later a request to the victim origin. The attacker must be able to set an arbitrary Set-Cookie Domain attribute on their response (trivial for an attacker-controlled server). Key limiting factors: happy-dom is primarily a headless/test DOM, so there is no impact in test-only usage; exploitation depends on this specific cross-origin fetch sequence in an SSR/prerender pipeline, and delivery of the forged cookie to the victim request is what grants the injection/session-fixation effect. No authentication on the victim origin is needed for the cookie to be planted and delivered.

This is a medium-severity cookie-scoping flaw (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) whose real-world priority is strongly gated by deployment context rather than raw score. Positive exploitation signals: a full, working proof-of-concept is published in the vendor GHSA advisory (with verbatim observed output confirming the endsWith/no-DNS-label-boundary bug and public-suffix acceptance), and the vuln.today decision label is 'this_month' - meaningful but below act_now/emergency. Tempering signals: it is NOT in CISA KEV (no confirmed active exploitation), and no EPSS probability was provided in the input, so the likelihood of widespread opportunistic exploitation cannot be quantified from available data. The dominant caveat - explicitly acknowledged by the reporter - is that happy-dom is primarily a headless/test DOM; the forgery only has security impact when happy-dom is used for server-side rendering or prerendering cookie handling in an application that contacts attacker-controlled origins and then a victim origin. In pure test usage the real risk is negligible. Net: a genuine but conditional issue - treat as a prompt dependency update for SSR/prerender deployments, not a drop-everything emergency.

An SSR or prerender service built on happy-dom (< 20.14.6) loads or scrapes an attacker-controlled page; the attacker's server responds with a Set-Cookie carrying a Domain attribute for an unrelated host or a public suffix (e.g. Domain=localhost from 127.0.0.1, or Domain=com). Because CookieContainer does not enforce a DNS-label boundary and does not reject public suffixes, happy-dom stores the mis-scoped cookie, and when the service subsequently fetches the victim origin the forged cookie is attached - enabling cookie injection or session fixation. A working PoC demonstrating this exact chain is published in the GHSA advisory.