CVE-2026-118660 in Happy DOMinfo

Summary

by MITRE • 10/28/2026

Happy DOM is a JavaScript implementation of a web browser without its graphical user interface. Prior to 21.0.0, Happy DOM loads iframe src URLs and link rel="stylesheet" href URLs by default while parsing untrusted HTML on the server because disableIframePageLoading and disableCSSFileLoading default to false. An attacker who controls parsed HTML can therefore cause server-side requests to arbitrary internal or cloud endpoints without an application opt-in and may expose confidential responses or credentials returned by those endpoints. This issue is fixed in version 21.0.0.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Analysis

by VulDB Data Team • 10/28/2026

Happy DOM serves as a headless JavaScript implementation of the browser environment, designed primarily for server-side rendering and testing scenarios where graphical user interface components are unnecessary. By emulating core web platform behaviors such as document object model manipulation and resource loading, it allows developers to execute client-side logic in non-browser environments. However, this emulation includes features that mirror standard browser security models, including the automatic fetching of external resources like iframe sources and stylesheet links during HTML parsing. Prior to version 21.0.0, these network-fetching capabilities were enabled by default through configuration flags disableIframePageLoading and disableCSSFileLoading being set to false. This default behavior creates a significant server-side request forgery vector when the library processes untrusted or user-supplied HTML content on the backend.

The core technical flaw lies in the unconditional execution of network requests triggered solely by the presence of specific HTML attributes during parsing operations. When an attacker controls the input HTML, they can inject elements such as iframes with src attributes pointing to internal services or external malicious domains, and link tags referencing stylesheets hosted on arbitrary endpoints. Because these actions occur automatically without explicit application opt-in, any server utilizing Happy DOM for rendering untrusted content becomes susceptible to initiating outbound connections from its own network identity. This effectively transforms the vulnerable service into a proxy that can be abused to probe internal networks or exfiltrate data via side channels if error messages are reflected back through CSS parsing mechanisms.

The operational impact of this vulnerability is severe, particularly in environments where servers have access to sensitive internal infrastructure such as metadata endpoints, authentication services, or private APIs. An attacker leveraging this flaw can cause the server to make requests that reveal confidential responses, session tokens, or other credentials stored at those target endpoints. This constitutes a classic Server-Side Request Forgery scenario, categorized under CWE-918 in industry standards for web application security flaws. Furthermore, because the attacks are initiated from within the trusted network perimeter of the hosting environment, they can bypass many external firewall rules and intrusion detection systems that do not monitor internal outbound traffic closely. The ability to read responses via CSS parsing errors or similar side-channel techniques further exacerbates the risk by enabling data exfiltration beyond simple connectivity testing.

To mitigate this vulnerability, organizations must immediately upgrade Happy DOM to version 21.0.0 or later, where these network loading features are disabled by default unless explicitly enabled by the developer. For applications that cannot update immediately due to compatibility constraints, it is critical to manually configure the library instance to disable iframe page loading and CSS file loading before processing any untrusted HTML input. This involves setting the respective configuration flags to true within the Happy DOM setup parameters. Additionally, developers should implement strict allowlists for any external resources required by their applications rather than relying on open parsing behaviors. Input validation strategies that sanitize or strip out potentially dangerous tags like iframe and link with href attributes can provide an additional layer of defense against injection attempts.

From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1598, specifically Phishing for Information within Systems, as it allows attackers to harvest data from internal systems by leveraging the victim server's network access. It also relates to T1071 Application Layer Protocol due to the abuse of standard HTTP/HTTPS protocols initiated by a legitimate application process. Security teams should audit their usage of headless browser libraries and ensure that any library capable of making outbound requests is configured with secure defaults. Regular security assessments focusing on server-side rendering components are essential to identify similar misconfigurations in other DOM manipulation tools. By treating untrusted HTML as potentially malicious code rather than passive data, developers can prevent the exploitation of these implicit network behaviors and maintain the integrity of their backend infrastructure against SSRF-based attacks.

Responsible

GitHub M

Reservation

10/28/2026

Disclosure

10/28/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to know what is going to be exploited?

We predict KEV entries!