Happy DOM Vulnerability: 2.7 Million Users Exposed To Remote Code Execution Attacks

In my review, I found that Happy DOM’s Node.js VM context isn’t truly isolated. Because JavaScript evaluation (via eval() and Function()) is enabled by default, untrusted code can escape the sandbox. In other words, an attacker could craft malicious JavaScript that climbs the constructor chain and gains access to the process-level Function constructor, breaking out of the supposed safe environment.

The type of module system (CommonJS vs ESM) matters here. In a CommonJS setup, the attacker might get access to the require() function, load Node.js modules, and perform unauthorized actions.

This vulnerability is a major concern especially for server-side rendering (SSR) frameworks or any server that processes external HTML content. Here are some of the attack scenarios I identified:

• Data exfiltration: The attacker could access environment variables, configuration files, secrets.
• Lateral movement: If the compromised server has network access, internal systems could be reached.
• Full code execution: Executing arbitrary commands by spawning child processes is possible.
• Persistence: The attacker could modify the filesystem to keep long-term footholds inside the system.

What to do

Here are the steps I’m recommending:

Disable evaluation: If an immediate update isn’t possible, turn off JavaScript evaluation unless you’re confident all processed content is fully trusted.

Update: Move to Happy DOM version 20 or newer, which disables JavaScript evaluation by default and shows a warning if you turn it on in an insecure environment.

Configuration: If you must use safe JavaScript evaluation, run Node.js with the --disallow-code-generation-from-strings flag. That blocks eval() and Function() at the process level.