Skip to main content
CVE-2025-61927VulnerabilityPublished

CVE-2025-61927: capricorn86 happy-dom · Code Injection

Affects capricorn86 happy-domSource CVE Database V5

0

Not known to be exploited · CVSS 7.2 High : upgrade to 20.0.0 soon.

Data as of 26 Oct 2026, 06:26 UTC

CVSS 4.0 base score
7.2High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.6% chance of exploitation in 30 days – higher than 50% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 20.0.0
CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:A/VC:L/VI:H/VA:H/SC:H/SI:H/SA:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 10 Oct 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-26.

What to do

Upgrade capricorn86 happy-dom to 20.0.0.

Affected software

ProductAffectedFixed in
capricorn86 happy-domAffected
  • <20.0.0
Fixed in
  • 20.0.0

AI-suggested

1. Upgrade all instances of Happy DOM to version 20.0.0 or later, where JavaScript evaluation is disabled by default, effectively mitigating the vulnerability. 2. Audit all Node.js applications and development pipelines to identify where Happy DOM is used, especially in contexts that execute untrusted or external JavaScript code. 3. Implement strict code review and validation processes to prevent untrusted code execution within Happy DOM VM contexts. 4. Where possible, isolate execution environments further by using containerization or sandboxing technologies that provide stronger isolation than Node.js VM Contexts. 5. Disable or restrict the use of CommonJS modules in environments where untrusted code execution is necessary, or switch to ESM modules with careful evaluation of their security implications. 6. Monitor application logs and system behavior for unusual activity indicative of code injection or sandbox escape attempts. 7. Educate developers and DevOps teams about the risks of enabling JavaScript evaluation by default and the importance of secure configuration. 8. Apply principle of least privilege to Node.js processes running Happy DOM to limit the potential damage from exploitation. 9. Stay informed about updates or patches from the Happy DOM project and related Node.js security advisories.

Description

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.

References

Community reviews

Loading reviews…