Summary
Happy DOM can make server-side requests when it parses attacker-controlled HTML containing iframe sources or stylesheet links. Because these resource loads are enabled by default in affected configurations, an attacker may reach internal services or cloud metadata endpoints and potentially obtain sensitive responses or credentials.
Happy DOM can make server-side requests when it parses attacker-controlled HTML containing iframe sources or stylesheet links. Because these resource loads are enabled by default in affected configurations, an attacker may reach internal services or cloud metadata endpoints and potentially obtain sensitive responses or credentials.
Affected context
The issue occurs in server-side applications that use Happy DOM to parse untrusted or partially trusted HTML and retain the default behavior for loading iframe and CSS resources. It is most relevant when the runtime can access internal networks, cloud metadata services, administrative interfaces, or other endpoints that are not directly exposed to the attacker.
The issue occurs in server-side applications that use Happy DOM to parse untrusted or partially trusted HTML and retain the default behavior for loading iframe and CSS resources. It is most relevant when the runtime can access internal networks, cloud metadata services, administrative interfaces, or other endpoints that are not directly exposed to the attacker.
Exploit preconditions
- Attack surface: Server-side HTML parsing through Happy DOM
- Required access: Ability to provide or influence HTML processed by the application
- Trigger point: Parsing an iframe
srcor stylesheethrefURL - Network condition: The server-side process must be able to connect to the targeted internal or external endpoint
- Why exploitation is possible: Resource loading is enabled by default, allowing attacker-controlled URLs to initiate outbound server-side requests
- Attack surface: Server-side HTML parsing through Happy DOM
- Required access: Ability to provide or influence HTML processed by the application
- Trigger point: Parsing an iframe
srcor stylesheethrefURL - Network condition: The server-side process must be able to connect to the targeted internal or external endpoint
- Why exploitation is possible: Resource loading is enabled by default, allowing attacker-controlled URLs to initiate outbound server-side requests
Why this happens
The underlying flaw is an unsafe default for external resource loading during server-side DOM parsing. Happy DOM processes attacker-influenced iframe and stylesheet URLs without requiring explicit application opt-in, allowing the parser to act as a network client on behalf of the attacker. This behavior maps to CWE-918: Server-Side Request Forgery, because untrusted input can influence requests made from a privileged server-side network position.
The underlying flaw is an unsafe default for external resource loading during server-side DOM parsing. Happy DOM processes attacker-influenced iframe and stylesheet URLs without requiring explicit application opt-in, allowing the parser to act as a network client on behalf of the attacker. This behavior maps to CWE-918: Server-Side Request Forgery, because untrusted input can influence requests made from a privileged server-side network position.
Potential impact
- Access to internal services that trust requests from the affected server
- Retrieval of cloud instance metadata or temporary credentials
- Exposure of confidential response content to the application or attacker
- Network reconnaissance against private address ranges
- Potential follow-on compromise if reachable services expose administrative functionality
- Access to internal services that trust requests from the affected server
- Retrieval of cloud instance metadata or temporary credentials
- Exposure of confidential response content to the application or attacker
- Network reconnaissance against private address ranges
- Potential follow-on compromise if reachable services expose administrative functionality
General mitigation guidance
Mitigation generally focuses on preventing untrusted markup from initiating network activity and reducing the network privileges of the parsing process.
Common defensive patterns include:
- Disable iframe page loading and external stylesheet loading by default for untrusted HTML
- Require explicit application opt-in for each class of external resource
- Enforce URL allowlists for approved schemes, hosts, ports, and resource types
- Block loopback, link-local, private, and reserved address ranges after DNS resolution
- Apply network egress controls and isolate HTML parsing workloads
- Avoid returning fetched resource content to untrusted callers
- Run the parser with least-privilege network and process permissions
Mitigation generally focuses on preventing untrusted markup from initiating network activity and reducing the network privileges of the parsing process.
Common defensive patterns include:
- Disable iframe page loading and external stylesheet loading by default for untrusted HTML
- Require explicit application opt-in for each class of external resource
- Enforce URL allowlists for approved schemes, hosts, ports, and resource types
- Block loopback, link-local, private, and reserved address ranges after DNS resolution
- Apply network egress controls and isolate HTML parsing workloads
- Avoid returning fetched resource content to untrusted callers
- Run the parser with least-privilege network and process permissions
How teams detect issues like this
Organizations can identify this risk through:
- Static analysis and code review checks for server-side DOM parsing of untrusted HTML
- Searches for enabled iframe or CSS resource loading in parser configuration
- Tests using internal, loopback, link-local, and cloud metadata target classes
- Egress monitoring for unexpected requests originating from HTML-processing services
- Network policies that alert on access to private address ranges or metadata endpoints
- Dependency and configuration policy checks that require explicit opt-in for external resource fetching
Automated security review tools may help flag parser configurations and outbound request paths that lack destination validation.
Organizations can identify this risk through:
- Static analysis and code review checks for server-side DOM parsing of untrusted HTML
- Searches for enabled iframe or CSS resource loading in parser configuration
- Tests using internal, loopback, link-local, and cloud metadata target classes
- Egress monitoring for unexpected requests originating from HTML-processing services
- Network policies that alert on access to private address ranges or metadata endpoints
- Dependency and configuration policy checks that require explicit opt-in for external resource fetching
Automated security review tools may help flag parser configurations and outbound request paths that lack destination validation.
