Happy DOM CVE-2025-61927

The consuming application must pass attacker-controlled HTML or JavaScript into a Happy DOM Window (e.g. document.write(), innerHTML, or SSR of user-supplied content) while JavaScript evaluation is enabled - which is the DEFAULT in v19 and lower, so no explicit opt-in is needed by the victim application. Capability depends on the module system: under CommonJS the attacker reaches the require() function for arbitrary module import and full RCE (child_process, fs), while under ESM the escape yields the process object but not require/import, limiting but not eliminating impact. Key LIMITING factors: the vulnerability is NOT triggerable against Happy DOM in isolation - it requires an application that actually evaluates untrusted content; it is absent once upgraded to v20.0.0 (JS eval off by default); and worst-case module-import RCE is specific to CommonJS runtimes.

Signals are mixed and point to a conditional rather than broadly-exploitable risk. The vendor CVSS 4.0 base score is 7.2 (High) with vector AV:N/AC:L/AT:P/PR:H/UI:A - the AT:P (attack requirement present), PR:H and UI:A metrics explicitly encode that meaningful preconditions must be met, namely that the host application deliberately runs untrusted JavaScript inside Happy DOM. EPSS is low-to-moderate at 0.64% (49th percentile), the CVE is NOT on the CISA KEV list, and there is no evidence of active exploitation, so the 'confirmed actively exploited' bar is not met. However, the GitHub Security Advisory (GHSA-37j7-fg3j-429f) ships complete, working proof-of-concept reproduction code for both CommonJS and ESM, so publicly available exploit code exists and the technical barrier to weaponization is low once the vulnerable integration pattern is present. Net: this is a real, patch-worthy issue (full process-level RCE on CommonJS deployments that render untrusted content) but it is NOT a drop-everything, internet-wide mass-exploitation event - risk is concentrated in applications that feed untrusted HTML/JS into Happy DOM (SSR of user content, or test suites running untrusted fixtures). Note a signal tension: the vendor vector marks PR:H (operator/config dependency), yet the actual attacker supplying malicious content typically needs no application credentials - the PR:H reflects the integrating application's responsibility, not an authentication gate on the attacker; verify against your specific deployment.

A Node.js application uses Happy DOM (v19 or lower, default settings) to server-render or test HTML that includes attacker-controlled content, e.g. window.document.write(userControlledHTML). Because JavaScript evaluation is enabled by default and the VM Context is not truly isolated, the attacker's injected <script> reaches out through this.constructor.constructor('return process')() to grab the Node process object; on CommonJS it then obtains require() for full module access. Working PoC code for exactly this is published in the GHSA advisory, so exploitation is straightforward wherever untrusted content flows into Happy DOM.