CVE-2025-61927

What it actually does

Happy DOM versions 19.x and earlier execute JavaScript by default inside a Node.js VM Context that should not be treated as a security sandbox. If an application passes attacker-controlled JavaScript, HTML, or DOM-manipulating content into Happy DOM evaluation paths, that code can escape the intended DOM execution boundary and reach Node.js process capabilities. In CommonJS contexts, an attacker may be able to recover access to require() and import sensitive modules such as child_process, fs, net, or http; in ESM contexts, the exact primitive may differ but can still expose process-level functionality. The result is potential remote code execution in the privileges of the Node.js process using Happy DOM, including command execution, file read/write, network access, data theft, and service disruption.

Why it matters to the business

Applications that use Happy DOM to process untrusted or semi-trusted content, such as server-side rendering, HTML sanitization/testing pipelines, scraping, template preview, email rendering, or browser-like automation, may allow an attacker to run commands on the host running the Node.js process. This can lead to compromise of application secrets, source code, build artifacts, customer data accessible to the process, lateral movement through internal network access, and outages if the process or host is altered or destroyed. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, but it has been public for an extended period and should be prioritized wherever Happy DOM handles untrusted input.

How an attack unfolds

An attacker first identifies functionality where an application parses or evaluates attacker-controlled content using Happy DOM, such as uploaded HTML, preview rendering, server-side DOM execution, dynamic testing, or automation workflows. Because JavaScript evaluation is enabled by default in affected Happy DOM versions, attacker-supplied script can run in the Happy DOM VM Context. The attacker then uses JavaScript sandbox-escape techniques to access Node.js process objects or reconstruct powerful functions. In CommonJS deployments, this may include obtaining require() and loading built-in modules such as child_process to execute operating system commands. After code execution is achieved, the attacker typically validates execution with a low-noise command, reads environment variables or configuration files, extracts tokens and credentials available to the process, writes persistence or web-accessible files if possible, and may use outbound network connections to exfiltrate data or stage additional tooling.

How to fix it

Upgrade Happy DOM to version 20.0.0 or later, where JavaScript evaluation is disabled by default, or use a build containing upstream fix commit 819d15ba289495439eda8be360d92a614ce22405. For environments consuming the SUSE package listed in the advisory, update kernel-livepatch-SLE15-SP6-RT_Update_0 to version 17-150600.3.1 or later as applicable. After upgrading, explicitly verify that JavaScript evaluation remains disabled unless there is a documented and reviewed business need. Do not treat Node.js VM Context as an isolation boundary for untrusted code. If untrusted content must be processed, run it in a separate hardened sandbox such as an isolated container, locked-down worker, or disposable execution environment with no secrets, no write access to sensitive paths, restricted filesystem access, restricted network egress, seccomp/AppArmor/SELinux controls where available, and least-privilege service credentials. Add dependency pinning and software composition analysis checks to prevent reintroduction of Happy DOM v19 or earlier.

How to confirm the fix worked

Confirm the installed dependency version with package manager metadata and lockfiles, for example by checking package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, or SBOM output for happy-dom versions 19.x or earlier. Verify that runtime dependency resolution does not pull a vulnerable transitive copy. In code, search for Happy DOM configuration or usage that enables script execution and confirm JavaScript evaluation is disabled by default after the upgrade. Run a controlled regression test using benign script input to ensure untrusted scripts are not executed. Where Happy DOM is used in backend services, validate that the process runs with least privilege and without unnecessary secrets. For the SUSE package, confirm the installed package version is 17-150600.3.1 or later using the platform package manager and patch inventory tooling.

Typical attack path

1. Find an application feature or backend workflow that uses Happy DOM to process attacker-controlled HTML, DOM content, or JavaScript.
2. Submit content containing script that is evaluated by Happy DOM because JavaScript evaluation is enabled by default in affected versions.
3. Use a Node.js VM escape technique to reach process-level objects or recover require() in a CommonJS runtime.
4. Import Node.js built-in modules such as child_process or fs to execute commands, read files, or modify application data.
5. Collect secrets from environment variables, configuration files, source directories, or service credentials available to the Node.js process.
6. Establish outbound connectivity or write files to stage additional payloads, exfiltrate data, or maintain access.
7. Clean up obvious artifacts or blend malicious script content into normal application input to avoid detection.

How to detect it

Look for evidence that untrusted content processed by Happy DOM attempted to access Node.js internals or spawn operating system commands. Relevant sources include application request logs, stored user-submitted HTML or templates, rendering/preview job payloads, CI job logs, Node.js application logs, process execution telemetry, EDR command-line events, container runtime audit logs, filesystem audit logs, and outbound proxy/DNS logs. Focus on Node.js processes that unexpectedly launch child processes such as sh, bash, cmd.exe, powershell.exe, curl, wget, python, perl, node, npm, or nc. Search submitted HTML and script content for sandbox-escape patterns such as constructor.constructor, return process, process.mainModule, require('child_process'), require("child_process"), child_process.exec, child_process.spawn, global.process, and module.constructor. Investigate reads of environment variables, package metadata, SSH keys, cloud credentials, service account tokens, or application configuration files shortly after Happy DOM processing events. Because there are no public campaign-specific indicators and the vulnerability enables arbitrary code execution, behavior-based detection is more reliable than static IOCs.

• happy-dom
• node_modules/happy-dom
• "happy-dom"
• require('child_process')
• require("child_process")
• child_process.exec
• child_process.execSync
• child_process.spawn
• child_process.spawnSync
• process.mainModule
• global.process
• constructor.constructor
• return process
• Function('return process')
• Function("return process")
• module.constructor
• process.env
• /bin/sh -c
• cmd.exe /c
• powershell.exe -Command
• curl http
• wget http

What your security team should do

• Inventory all applications, build systems, test harnesses, renderers, and automation services that depend on happy-dom, including transitive dependencies and vendored copies.
• Prioritize remediation for any internet-facing, user-facing, CI/CD, or content-processing workflow that passes untrusted input into Happy DOM.
• Upgrade Happy DOM to 20.0.0 or later, or a build containing commit 819d15ba289495439eda8be360d92a614ce22405; update the referenced SUSE package to 17-150600.3.1 or later where applicable.
• Add CI policy to fail builds that include happy-dom versions 19.x or earlier.
• Review code paths for script execution, eval-like behavior, dynamic DOM parsing, and assumptions that Node.js VM Context provides security isolation.
• If untrusted script execution is required, move execution to a hardened, isolated sandbox with strict filesystem, secret, and network controls.
• Rotate credentials and tokens available to any Node.js process that may have evaluated untrusted content while running a vulnerable Happy DOM version.
• Search historical logs, submitted content, and application artifacts for Node.js sandbox-escape patterns and unexpected child process execution from Node.js.
• Add runtime detections for Node.js processes spawning shells, network utilities, interpreters, or package managers in services that normally only parse/render DOM content.