CVE-2025-61927 in happy-dom
Summary
by MITRE • 10/10/2025
Happy DOM is a JavaScript implementation of a web browser without its graphical user interface. Happy DOM v19 and lower contains a security vulnerability that puts the owner system at the risk of RCE (Remote Code Execution) attacks. A Node.js VM Context is not an isolated environment, and if the user runs untrusted JavaScript code within the Happy DOM VM Context, it may escape the VM and get access to process level functionality. It seems like what the attacker can get control over depends on if the process is using ESM or CommonJS. With CommonJS the attacker can get hold of the `require()` function to import modules. Happy DOM has JavaScript evaluation enabled by default. This may not be obvious to the consumer of Happy DOM and can potentially put the user at risk if untrusted code is executed within the environment. Version 20.0.0 patches the issue by changing JavaScript evaluation to be disabled by default.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2025
CVE-2025-61927 represents a critical remote code execution vulnerability within the Happy DOM JavaScript library, a headless browser implementation designed for server-side rendering and testing environments. This vulnerability stems from the improper isolation of Node.js VM contexts within the library's architecture, creating a dangerous attack surface where untrusted JavaScript code executed within Happy DOM's virtual environment can potentially escape containment and gain access to underlying system resources. The flaw specifically affects versions 19 and lower, where the default configuration enables JavaScript evaluation without adequate sandboxing mechanisms. The vulnerability manifests through the fundamental design flaw that Node.js VM contexts, while intended to provide isolation, are not sufficiently isolated from the host process, allowing privilege escalation when malicious code is executed within the controlled environment. This security weakness directly maps to CWE-242, which describes the use of dangerous functions that can lead to code execution vulnerabilities, and aligns with ATT&CK technique T1059.007 for JavaScript-based execution within compromised environments.
The technical exploitation of this vulnerability occurs through the manipulation of JavaScript evaluation capabilities that are enabled by default in Happy DOM's configuration. When users execute untrusted code within the library's context, particularly within CommonJS environments, attackers can leverage the availability of the require() function to import and execute arbitrary modules with elevated privileges. This privilege escalation capability represents a significant operational risk as it allows attackers to access system-level functionality that should remain restricted within a sandboxed environment. The vulnerability's impact is exacerbated by the fact that many developers may not be aware of this default behavior, creating a false sense of security when integrating Happy DOM into their applications. The transition from CommonJS to ESM environments does not fully mitigate the risk, as both execution contexts can potentially be exploited through different attack vectors, though CommonJS provides more direct access to module loading mechanisms.
The operational implications of CVE-2025-61927 extend beyond simple code execution, as it fundamentally compromises the security model of applications relying on Happy DOM for testing or rendering tasks. Organizations using vulnerable versions face potential data breaches, system compromise, and unauthorized access to sensitive resources when processing untrusted input through the library. The vulnerability is particularly concerning in continuous integration environments, testing frameworks, and server-side rendering applications where untrusted user input might be processed through Happy DOM's JavaScript evaluation capabilities. The patch implemented in version 20.0.0 addresses this by disabling JavaScript evaluation by default, which aligns with the principle of least privilege and security by default practices. This mitigation strategy represents a fundamental shift in the library's security posture, moving from an assumption that users will properly secure their environments to an approach where the library itself provides adequate protection against malicious code execution.
Security practitioners should prioritize immediate patching of affected systems and implement comprehensive monitoring for any suspicious JavaScript execution patterns within environments using Happy DOM. The vulnerability demonstrates the critical importance of proper sandboxing mechanisms in JavaScript environments and highlights the need for developers to understand the security implications of enabling potentially dangerous features like JavaScript evaluation. Organizations should also consider implementing additional security controls such as input validation, code review processes, and runtime monitoring to detect potential exploitation attempts. The vulnerability serves as a reminder of the broader security challenges in modern JavaScript ecosystems where libraries often provide convenient but potentially dangerous features without adequate default security configurations, emphasizing the need for security-conscious library design and proper threat modeling in development practices.