CVE-2024-51757

What it actually does

happy-dom versions prior to 15.10.2 can execute JavaScript from an HTML script tag in the host Node.js context when attacker-controlled markup is processed. Because happy-dom is commonly used for server-side DOM emulation in tests, rendering pipelines, crawlers, sanitizers, or automation, this can cross the intended boundary between parsed web content and the local runtime. Successful exploitation can allow arbitrary code execution with the privileges of the process using happy-dom, including access to environment variables, local files available to that user, network egress, and any credentials or tokens loaded into the process.

Why it matters to the business

If an application, CI job, test runner, build system, crawler, or backend service processes untrusted HTML with a vulnerable happy-dom version, an attacker may be able to run commands in that process context. This can lead to source code or secret theft, tampering with build artifacts, compromise of CI/CD credentials, service disruption, or lateral movement from developer and automation environments. The vulnerability is not currently in CISA KEV, has low EPSS, and has no known public exploit maturity in the supplied data, but the impact is high where untrusted HTML reaches happy-dom.

How an attack unfolds

An attacker first identifies functionality that accepts or retrieves attacker-controlled HTML and processes it using happy-dom before version 15.10.2. The attacker supplies markup containing a script element crafted to execute during DOM parsing or document evaluation. Instead of remaining safely isolated as browser-like script, the code executes in the Node.js host context used by happy-dom. From there, the attacker can interact with the runtime capabilities available to that process, such as reading environment variables, accessing files, making outbound network connections, or spawning child processes if those capabilities are reachable. In CI/CD or test environments, this may expose repository secrets, package publishing tokens, cloud credentials, or build artifacts. No named threat actors or ransomware campaigns are associated with this CVE in the supplied data.

How to fix it

Upgrade happy-dom to version 15.10.2 or later. For source-based use of capricorn86/happy-dom, update to a revision including commit d23834c232f1cf5519c9418b073f1dcec6b2f0fd or newer. Regenerate and redeploy lockfiles after upgrading, including package-lock.json, yarn.lock, pnpm-lock.yaml, or other dependency manifests. If the Ubuntu chromium-browser package entry is relevant in your asset inventory, ensure Ubuntu 14.04 LTS chromium-browser is updated to 47.0.2526.106-0ubuntu0.14.04.1.1107 or later; however, the primary described vulnerable component is happy-dom. There are no known workarounds for the happy-dom issue. As compensating controls, do not process untrusted HTML with vulnerable versions, isolate DOM-processing workloads in containers or sandboxes with minimal privileges, remove secrets from test and rendering processes, restrict network egress, and run CI jobs with least-privilege credentials.

How to confirm the fix worked

Confirm that all package manifests and lockfiles resolve happy-dom to 15.10.2 or later. Use package-manager inventory commands such as npm ls happy-dom, yarn why happy-dom, pnpm why happy-dom, or software composition analysis tooling to identify both direct and transitive use. Inspect deployed artifacts and containers for node_modules/happy-dom/package.json and verify the version field. Confirm CI images, test runners, serverless bundles, and build containers have been rebuilt after dependency updates. Validate that untrusted HTML processing paths no longer use vulnerable happy-dom versions, and where feasible run a safe regression test that verifies script tags in parsed untrusted content do not execute in the host context.

Typical attack path

1. Find an application, backend workflow, crawler, renderer, sanitizer, test harness, or CI job that uses happy-dom before 15.10.2.
2. Determine whether attacker-controlled HTML is passed into happy-dom or into code paths that create a happy-dom window or document.
3. Submit or host HTML containing a script tag intended to execute during DOM processing.
4. Trigger the vulnerable code path so the HTML is parsed or evaluated by happy-dom.
5. Gain code execution in the Node.js process context running happy-dom.
6. Access sensitive runtime data such as environment variables, filesystem content, tokens, source code, or network-reachable services.
7. Persist, exfiltrate data, alter build outputs, or pivot depending on the privileges and network access of the affected process.

How to detect it

To determine whether this was already exploited, focus on places where happy-dom processed untrusted or semi-trusted HTML: CI logs, test runner output, backend application logs, container logs, package-rendering services, crawlers, and server-side DOM automation jobs. Look for HTML submissions or fetched pages containing unexpected script tags followed by anomalous Node.js behavior. On hosts and containers, review process creation telemetry for node, npm, yarn, pnpm, jest, vitest, mocha, playwright-adjacent tooling, or custom render workers spawning shells or system utilities unexpectedly. Review EDR, auditd, Sysmon, shell history, and container runtime logs for child processes launched by Node.js, unusual file reads from repository directories, access to .env files or cloud credential paths, and unexpected outbound connections shortly after DOM parsing jobs. In CI/CD platforms, examine workflow logs for injected script content, unexpected environment-variable printing, curl/wget usage, package publishing actions, credential errors, or artifact modifications. Network telemetry should be checked for outbound connections from build runners or DOM-processing services to unfamiliar domains or IPs. Because there are no supplied public exploit indicators, detections should be behavior-based and correlated with use of happy-dom versions earlier than 15.10.2.

• node_modules/happy-dom/package.json
• "happy-dom": "15.10.1"
• "happy-dom": "15.10.0"
• "happy-dom": "15.
• happy-dom@15.10.1
• happy-dom@15.10.0
• happy-dom@15.9.
• happy-dom@15.8.
• happy-dom@15.7.
• happy-dom@15.6.
• happy-dom@15.5.
• happy-dom@15.4.
• happy-dom@15.3.
• happy-dom@15.2.
• happy-dom@15.1.
• happy-dom@15.0.
• require('child_process')
• require("child_process")
• child_process.exec
• child_process.execSync
• child_process.spawn
• process.mainModule
• process.env
• <script>
• </script>
• curl
• wget
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe

What your security team should do

• Prioritize remediation for CI/CD systems, developer tooling, crawlers, backend renderers, and services that process externally supplied HTML using happy-dom.
• Upgrade happy-dom to 15.10.2 or later and rebuild all containers, packages, and deployment artifacts that may have bundled the vulnerable dependency.
• Search source repositories and lockfiles for happy-dom versions below 15.10.2, including transitive dependencies.
• Temporarily block or disable workflows that process untrusted HTML with vulnerable happy-dom versions until upgraded.
• Remove unnecessary secrets from Node.js processes that perform DOM parsing, especially in test and CI environments.
• Restrict outbound network access from build and parsing workloads to reduce the impact of possible code execution.
• Review recent executions of affected pipelines or services for suspicious child processes, unexpected network connections, and secret-access activity.
• Add dependency scanning policy gates that fail builds when happy-dom versions below 15.10.2 are introduced.