A critical security flaw has been identified in Happy DOM, a widely used JavaScript library primarily employed for server-side rendering and testing frameworks. The vulnerability, cataloged as CVE-2025-61927, allows attackers to escape the library’s virtual machine (VM) context, leading to potential remote code execution on vulnerable systems. This flaw threatens millions of applications that depend on Happy DOM.
Understanding the VM Context Escape Vulnerability (CVE-2025-61927) in Happy DOM
The root of this vulnerability lies in the improper isolation of the Node.js VM context within Happy DOM versions 19 and earlier. The VM context is intended to act as a secure sandbox, allowing untrusted code to execute without compromising the host system. However, this isolation is flawed, enabling malicious JavaScript code to escape the sandbox and gain access to higher-level system functions.
Security researcher Mas0nShi uncovered that the vulnerability exploits the inheritance chain of JavaScript constructors. By walking up the constructor chain from the context’s objects, attackers can reach the global Function constructor, which permits the evaluation of arbitrary code strings. This effectively breaks the containment and allows code execution at the process level, bypassing the VM context safeguards.
The attack differs depending on the module system in use: CommonJS or ECMAScript modules (ESM). Systems running CommonJS are particularly exposed, as attackers can access the require() function, enabling them to import and execute additional modules, increasing the attack surface. In contrast, ESM environments limit access to import or require, reducing some capabilities but still allowing process-level information retrieval.
Scope and Impact
Happy DOM is widely adopted for server-side rendering (SSR) and testing environments that process user-generated or untrusted HTML content. The flaw impacts roughly 2.7 million users who rely on the library for rendering and testing JavaScript applications. The most at-risk applications are those that dynamically render user-controlled content, creating an opportunity for attackers to inject and execute malicious scripts.
Typical attack scenarios include:
- Data Exfiltration: Attackers may gain access to sensitive environment variables, configuration files, or secret tokens.
- Lateral Movement: Malicious actors could exploit network access within the environment to move laterally across systems, although Happy DOM does implement some network protections like CORS.
- Code Execution: Attackers may run arbitrary commands by leveraging child processes.
- Persistence: File system access could enable attackers to modify or persist malicious payloads on the host.
Technical Details and Reproduction
In CommonJS setups, attackers can obtain the require() function via the escape, allowing the import of core Node.js modules like fs to read files:
const { Window } = require(‘happy-dom’);
const window = new Window({ console });window.document.write(`
<script>
const process = this.constructor.constructor(‘return process’)();
const require = process.mainModule.require;console.log(‘Files:’, require(‘fs’).readdirSync(‘.’).slice(0,3));
</script>
`);
In ECMAScript module contexts, although importing modules is restricted, attackers can still access the process object and obtain process-level information, such as the PID:
const { Window } = require(‘happy-dom’);
const window = new Window({ console });window.document.write(`
<script>
const process = this.constructor.constructor(‘return process’)();console.log(‘PID:’, process.pid);
</script>
`);
The crux of the issue is that the JavaScript evaluation feature in Happy DOM is enabled by default, which is not always apparent to users and poses risks when handling untrusted code.
Response and Recommendations
The vulnerability has been addressed in Happy DOM version 20, where JavaScript evaluation is disabled by default. This release also includes warnings when JavaScript evaluation is enabled in potentially insecure environments.
Users are strongly advised to upgrade to version 20 or later immediately to mitigate the risk of exploitation. For those who cannot upgrade right away, disabling JavaScript evaluation entirely is recommended unless the content processed is fully trusted.
Additional hardening can be achieved by running Node.js with the –disallow-code-generation-from-strings flag. This flag prevents string-based code generation methods like eval() and Function() from running at the process level, effectively blocking the VM context escape even if JavaScript evaluation is enabled in Happy DOM. Notably, eval() and Function() remain usable safely within the isolated Happy DOM VM context itself.
