Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
happy-dom v20.8.9 makes real server-side HTTP requests to arbitrary URLs when parsing HTML containing ` ` or ` ` elements. This behavior is enabled by default (`disableIframePageLoading: false`, `disableCSSFileLoading: false`). When an application uses happy-dom to parse untrusted HTML on the server side, an attacker can trigger Server-Side Request Forgery by embedding these elements. Affected Versions - happy-dom ` stylesheets fetch their `href` URL via real HTTP requests When untrusted HTML is parsed, these elements trigger real server-side HTTP requests to whatever URLs are specified. No special configuration or opt-in is needed. Proof of Concept Verified test (attacker server receives requests): ```javascript const http = require('http'); const { Window } = require('happy-dom'); // Start attacker server const srv = http.createServer((req, res) => { console.log(`SSRF HIT: ${req.method} ${req.url}`); res.writeHead(200, {'Content-Type': 'text/html'}); res.end('…
Recommended action: Upgrade to 21.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A cookie-scoping bug in happy-dom lets an attacker origin set cookies that a victim origin then receives, diverging from browser semantics. Details happy-dom matches Domain=example.com against notexample.com (endsWith without a DNS-label boundary), diverging from browser semantics (verified 20.11.6 npm latest: cookieMatchesURL(Domain=example.com, url=http://notexample.com) = true). Relevant where happy-dom is used for SSR/prerender cookie handling. Matching in src/cookie/CookieContainer.ts. PoC Run: ```bash node poc-happydom-cookie-domain.js ``` Full proof-of-concept source (poc-happydom-cookie-domain.js): ```js // PoC: happy-dom cookie-domain scoping gap -> cross-origin cookie injection / session fixation // Chain: app (window at http://localhost:PORT2) fetches attacker server (http://127.0.0.1:PORT1) // -> attacker Set-Cookie with Domain=localhost (a host that is NOT a suffix of 127.0.0.1) // -> happy-dom stores it (a real browser rejects: RFC 6265 §5.3.6-7 +…
Recommended action: Upgrade to 20.14.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ESM compiler in happy-dom@20.14.5 does not validate imported local binding aliases before interpolating them into generated JavaScript. As a result, an invalid ESM import alias can be transformed into a valid JavaScript destructuring default initializer and executed. This appears to be an alternate injection path and incomplete remediation of GHSA-6q6h-j7hj-3r64 / CVE-2026-33943. The previous fix validates importName in the local export { ... } handler, but the named import handler still places an unvalidated alias directly into code context. These issues were confirmed through the public Window and <script type="module" APIs using the published happy-dom npm package. The PoC reaches the Node.js host process, obtains node:fs, and creates a proof directory on the host filesystem. Confirmed affected versions The PoC was directly tested against: - happy-dom@17.0.0 - happy-dom@20.0.0 - happy-dom@20.1.0 - happy-dom@20.14.5 The same PoC does not trigger on happy-dom@16.8.1. The…
Recommended action: Upgrade to 21.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
happy-dom may attach cookies from the current page origin (window.location) instead of the request target URL when fetch(..., { credentials: "include" }) is used. This can leak cookies from origin A to destination B. Details In packages/happy-dom/src/fetch/utilities/FetchRequestHeaderUtility.ts (getRequestHeaders()), cookie selection is performed with originURL: Here, originURL represents the page URL, not the request destination URL. For outgoing requests, cookie lookup should use the request URL (for example: new URL(options.request[PropertySymbol.url])). PoC Script Content Environment: 1. Node.js = 22 2. happy-dom 20.6.1 3. DNS names resolving to local loopback via .127.0.0.1.nip.io Reproduction steps: 1. Set page host cookie: pagecookie=PAGEONLY on a.127.0.0.1.nip.io 2. Set target host cookie: apicookie=APIONLY on b.127.0.0.1.nip.io 3. From page host, call fetch to target host with credentials: "include" 4. Observe Cookie header received by the target host Expected: 1.…
Recommended action: Upgrade to 20.8.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A code injection vulnerability in ECMAScriptModuleCompiler allows an attacker to achieve Remote Code Execution (RCE) by injecting arbitrary JavaScript expressions inside export { } declarations in ES module scripts processed by happy-dom. The compiler directly interpolates unsanitized content into generated code as an executable expression, and the quote filter does not strip backticks, allowing template literal-based payloads to bypass sanitization. Details Vulnerable file: packages/happy-dom/src/module/ECMAScriptModuleCompiler.ts, lines 371-385 The "Export object" handler extracts content from export { ... } using the regex export\s{([^}]+)}, then generates executable code by directly interpolating it: } else if (match[16] && isTopLevel && PRECEDINGSTATEMENTTOKENREGEXP.test(precedingToken)) { // Export object const parts = this.removeMultilineComments(match[16]).split(/\s,\s/); const exportCode: string[] = []; for (const part of parts) { const nameParts =…
Recommended action: Upgrade to 20.8.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The mitigation proposed in GHSA-37j7-fg3j-429f for disabling eval/Function when executing untrusted code in happy-dom does not suffice, since it still allows prototype pollution payloads. Details The untrusted script and the rest of the application still run in the same Isolate/process, so attackers can deploy prototype pollution payloads to hijack important references like "process" in the example below, or to hijack control flow via flipping checks of undefined property. There might be other payloads that allow the manipulation of require, e.g., via (univeral) gadgets (https://www.usenix.org/system/files/usenixsecurity23-shcherbakov.pdf). PoC Attackers can pollute builtins like Object.prototype.hasOwnProperty() to obtain important references at runtime, e.g., "process". In this way, attackers might be able to execute arbitrary commands like in the example below via spawn(). Impact Arbitrary code execution via breaking out of the Node.js' vm isolation. Recommended Immediate…
Recommended action: Upgrade to 20.0.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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) ESM (Not possible to get hold of import or require) Potential Impact Server-Side Rendering (SSR) Testing Frameworks Any test suite using…
Recommended action: Upgrade to 20.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Consumers of the NPM package happy-dom Patches The security vulnerability has been patched in v15.10.2 Workarounds No easy workarounds to my knowledge References #1585
Recommended action: Upgrade to 15.10.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.