happy-dom EUVD-2026-112467

Requires that the application use happy-dom on the server to parse HTML an attacker can influence, running an affected version (<= 20.14.6) with the default settings disableIframePageLoading: false and disableCSSFileLoading: false, and that the attacker-supplied HTML include an <iframe src> or <link rel="stylesheet" href> pointing at an internal or cloud-metadata URL. No authentication, user interaction, or opt-in configuration is needed on those defaults (AV:N/AC:L/PR:N/UI:N). Exploitation is LIMITED where the application does not feed untrusted HTML to happy-dom, where the operator has already set disableIframePageLoading/disableCSSFileLoading to true (or upgraded to 21.0.0 where loading is off by default), or where egress to internal ranges and 169.254.169.254 is blocked at the network layer; per the advisory, iframe srcdoc content is not affected.

This is a genuine, actionable SSRF (CWE-918) rather than a paper-high CVSS. The supplied CVSS:3.1 vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N (8.6) is internally consistent with the mechanism: an attacker who controls parsed HTML needs no authentication and no victim interaction, and the scope change (S:C) correctly reflects that the forged request reaches systems other than happy-dom itself - internal services and cloud metadata endpoints. The GHSA advisory includes a verified proof-of-concept whose test output ('SSRF HIT: GET /iframe-ssrf' and '/stylesheet-ssrf') confirms the requests actually fire against default settings, so exploitability is demonstrated, not theoretical. Counter-signals: the CVE is NOT listed in CISA KEV, so there is no confirmed active exploitation, and no EPSS score, SSVC decision string, or 'automatable' rating was provided in the input, so the probabilistic widespread-exploitation picture cannot be stated - do not treat the demonstrated PoC as evidence of in-the-wild use. The vuln.today priority label is 'this_week', consistent with a serious-but-not-emergency item. The one real caveat is the actual blast radius being fully conditional on application wiring (the server must parse attacker-influenced HTML with happy-dom), which the raw 8.6 does not capture. Net: prioritize patching to 21.0.0 this week; the confidentiality impact is real where the vulnerable usage pattern exists.

An application uses happy-dom server-side to parse HTML it does not fully control (e.g. web scraping, email/HTML rendering, or SSR of user-supplied markup). An attacker submits HTML containing <iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/"> or <link rel="stylesheet" href="http://internal-service/...">, and happy-dom issues a real server-side GET to that URL, returning or exposing cloud IAM credentials or internal API responses. A verified proof-of-concept exists in the GHSA-c8p4-j97h-3vg8 advisory, and because the vector is AV:N/AC:L/PR:N/UI:N no authentication, special complexity, or user interaction is required against default (<=20.14.6) configurations.