Summary
Happy DOM contains a code injection flaw in its ECMAScript module compiler that can place an unvalidated import alias into generated JavaScript. When JavaScript evaluation is enabled and attacker-controlled HTML or module source is processed, this may cause code to execute in the Node.js host process.
Happy DOM contains a code injection flaw in its ECMAScript module compiler that can place an unvalidated import alias into generated JavaScript. When JavaScript evaluation is enabled and attacker-controlled HTML or module source is processed, this may cause code to execute in the Node.js host process.
Affected context
The vulnerability affects Happy DOM deployments within the impacted 17.0.0 through 21.0.4 release range when JavaScript evaluation is enabled. It arises in the ESM compilation path when attacker-controlled module or HTML content can supply a named import alias that is inserted into a generated destructuring binding without being checked as a valid JavaScript binding identifier. A reachable scenario involves JSON module import attributes and generated circular-import handling.
The vulnerability affects Happy DOM deployments within the impacted 17.0.0 through 21.0.4 release range when JavaScript evaluation is enabled. It arises in the ESM compilation path when attacker-controlled module or HTML content can supply a named import alias that is inserted into a generated destructuring binding without being checked as a valid JavaScript binding identifier. A reachable scenario involves JSON module import attributes and generated circular-import handling.
Exploit preconditions
- Attack surface: Happy DOM's ECMAScript module compilation and evaluation functionality
- Required access: The ability to provide or influence HTML or module source processed by the application
- Trigger point: Compilation and evaluation of an ESM import with a named alias
- Required configuration: JavaScript evaluation must be enabled
- Why exploitation is possible: The alias is incorporated into generated JavaScript without validation, allowing compiler output to acquire unintended executable semantics while remaining syntactically valid in the relevant import-flow scenario
- Attack surface: Happy DOM's ECMAScript module compilation and evaluation functionality
- Required access: The ability to provide or influence HTML or module source processed by the application
- Trigger point: Compilation and evaluation of an ESM import with a named alias
- Required configuration: JavaScript evaluation must be enabled
- Why exploitation is possible: The alias is incorporated into generated JavaScript without validation, allowing compiler output to acquire unintended executable semantics while remaining syntactically valid in the relevant import-flow scenario
Why this happens
The underlying bug is insufficient validation of a user-controlled identifier during source-code generation. The compiler accepts a named ESM import alias without confirming that it conforms to JavaScript binding-identifier rules, then inserts it into a generated destructuring binding. This maps to CWE-94: Improper Control of Generation of Code ('Code Injection'), because input data can influence executable JavaScript produced for evaluation. The issue represents a residual validation gap in a related remediation: one import-name path was checked, while the named-import alias path remained trusted.
The underlying bug is insufficient validation of a user-controlled identifier during source-code generation. The compiler accepts a named ESM import alias without confirming that it conforms to JavaScript binding-identifier rules, then inserts it into a generated destructuring binding. This maps to CWE-94: Improper Control of Generation of Code ('Code Injection'), because input data can influence executable JavaScript produced for evaluation. The issue represents a residual validation gap in a related remediation: one import-name path was checked, while the named-import alias path remained trusted.
Potential impact
- An attacker could execute JavaScript in the Node.js host process
- The application may suffer confidentiality, integrity, or availability loss
- Host environment secrets or accessible files could be exposed
- The process could be used for unauthorized network activity or lateral movement
- Test, rendering, or server-side automation workloads could be compromised
- An attacker could execute JavaScript in the Node.js host process
- The application may suffer confidentiality, integrity, or availability loss
- Host environment secrets or accessible files could be exposed
- The process could be used for unauthorized network activity or lateral movement
- Test, rendering, or server-side automation workloads could be compromised
General mitigation guidance
Mitigation generally focuses on treating all source-level names as untrusted before they reach code-generation logic.
Defensive patterns include:
- Validate every generated binding, including named import aliases, against the language's binding-identifier grammar
- Prefer structured parsers, AST transformations, or safe module APIs over string-based source generation
- Reject malformed or unexpected module identifiers before compilation and before evaluation
- Keep JavaScript evaluation disabled unless the application requires it
- Isolate evaluated content in a least-privileged process or sandbox with restricted filesystem, network, and credential access
- Apply consistent validation across initial imports, re-exports, and circular-import bookkeeping paths
- Treat HTML, module source, and import metadata as untrusted input regardless of their apparent origin
Mitigation generally focuses on treating all source-level names as untrusted before they reach code-generation logic.
Defensive patterns include:
- Validate every generated binding, including named import aliases, against the language's binding-identifier grammar
- Prefer structured parsers, AST transformations, or safe module APIs over string-based source generation
- Reject malformed or unexpected module identifiers before compilation and before evaluation
- Keep JavaScript evaluation disabled unless the application requires it
- Isolate evaluated content in a least-privileged process or sandbox with restricted filesystem, network, and credential access
- Apply consistent validation across initial imports, re-exports, and circular-import bookkeeping paths
- Treat HTML, module source, and import metadata as untrusted input regardless of their apparent origin
How teams detect issues like this
Detection can combine static analysis, review controls, and runtime policy enforcement:
- Search for generated JavaScript that interpolates import names or aliases without identifier validation
- Use static-analysis rules to flag string concatenation or template generation involving module-source tokens
- Review compiler paths for inconsistent validation between local names, aliases, re-exports, and circular-import assignments
- Add negative tests for invalid binding identifiers across ordinary, JSON-module, and circular-import flows
- Enforce policies that restrict JavaScript evaluation in server-side DOM environments
- Monitor evaluated Node.js processes for unexpected child-process creation, filesystem access, or outbound connections
- Automated code-review and dependency-analysis tools may help identify unsafe code-generation patterns and affected dependency usage
Detection can combine static analysis, review controls, and runtime policy enforcement:
- Search for generated JavaScript that interpolates import names or aliases without identifier validation
- Use static-analysis rules to flag string concatenation or template generation involving module-source tokens
- Review compiler paths for inconsistent validation between local names, aliases, re-exports, and circular-import assignments
- Add negative tests for invalid binding identifiers across ordinary, JSON-module, and circular-import flows
- Enforce policies that restrict JavaScript evaluation in server-side DOM environments
- Monitor evaluated Node.js processes for unexpected child-process creation, filesystem access, or outbound connections
- Automated code-review and dependency-analysis tools may help identify unsafe code-generation patterns and affected dependency usage
