NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
📦 npm
Not in CISA KEV

Happy DOM: VM Context Escape can lead to Remote Code ExecutionGHSA-37j7-fg3j-429f

Fix: capricorn86/happy-dom@819d15b

GHSA-37j7-fg3j-429f is a Code Injection vulnerability in happy-dom. A fix is available for happy-dom — see the affected versions and patch details below.

Also known asCVE-2025-61927
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Nov 6, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for GHSA-37j7-fg3j-429f.

EPSS Exploitation Probability

via FIRST.org ↗
0.6%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs51th percentile — riskier than 51% of all scored CVEsHighest risk
0.00%0.38%0.76%1.14%0.4%0.6%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

Real-World Exposure

1 pkg affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

371other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
happy-domnpm
33.0Mdownloads / week

Description

Escape of VM Context gives access to process level functionality

Summary

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.

Reproduce

CommonJS (Possible to get hold of require)

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>
`);

ESM (Not possible to get hold of import or require)

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>
`);

Potential Impact

Server-Side Rendering (SSR)

const { Window } = require('happy-dom');
const window = new Window();
window.document.innerHTML = userControlledHTML;

Testing Frameworks

Any test suite using Happy-DOM with untrusted content may be at risk

Attack Scenarios

  1. Data Exfiltration: Access to environment variables, configuration files, secrets
  2. Lateral Movement: Network access for connecting to internal systems. Happy DOM already gives access to the network by fetch, but has protections in place (such as CORS and header validation etc.).
  3. Code Execution: Child process access for running arbitrary commands
  4. Persistence: File system access

Recommended Immediate Actions

  1. Update Happy DOM to v20 or above
    • This version has JavaScript evaluation disabled by default
    • This version will output a warning if JavaScript is enabled in an insecure environment
  2. Run Node.js with the "--disallow-code-generation-from-strings" if you need JavaScript evaluation enabled
    • This makes sure that evaluation can't be used at process level to escape the VM
    • eval() and Function() can still be used within the Happy DOM VM without any known security risk
    • Happy DOM v20 and above will output a warning if this flag is not in use
  3. If you can't update Happy DOM right now, it's recommended to disable JavaScript evaluation, unless you completely trust the content within the environment

Technical Root Cause

All classes and functions inherit from Function. By walking the constructor chain it's possible to get hold of Function at process level. As Function can evaluate code from strings, it's possible to execute code at process level.

Running Node with the "--disallow-code-generation-from-strings" flag protects against this.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
📦npmhappy-domall versions20.0.0npm install happy-dom@20.0.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for happy-dom, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update happy-dom to 20.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-37j7-fg3j-429f is resolved across your whole dependency graph.

  3. Workarounds

    Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant
Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.
Source: Red Hat security advisory for GHSA-37j7-fg3j-429f (CC BY 4.0)
ProductFixed inAdvisory
Red Hat OpenShift Dev Spaces (RHOSDS) 3.25devspaces/traefik-rhel9:3.25.0-1764892466RHSA-2025:23225

Frequently Asked Questions

# Escape of VM Context gives access to process level functionality ## Summary 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 impor
O3 Security · Impact-Aware SCA

Is GHSA-37j7-fg3j-429f in your dependencies?

Find it across npm, including transitive dependencies.

Happy DOM: VM Context Escape can lead to Remote…