GHSA-x4vx-rjvf-j5p4

What it actually does

This is a Cross-Site Scripting (XSS) vulnerability in the DOMPurify library. When DOMPurify is configured with the `IN_PLACE: true` option, it improperly trusts the `nodeName` property of certain DOM nodes supplied by the user. This allows an attacker to provide a crafted DOM object with a malicious `nodeName` that bypasses sanitization. As a result, arbitrary JavaScript can be retained in the DOM and executed within the security context of the user's browser, leading to a full compromise of the client-side application logic.

Why it matters to the business

Exploitation of this vulnerability can lead to significant business harm. Attackers can steal sensitive user data, including session cookies and authentication tokens, leading to account takeovers and data breaches. This can result in financial loss, reputational damage, and a loss of customer trust. Furthermore, compromised applications could be used to spread malware or launch phishing attacks against users, potentially leading to regulatory fines and legal liabilities.

How an attack unfolds

An attacker first identifies a web application that uses a vulnerable version of DOMPurify and processes user-supplied content with the `IN_PLACE` setting enabled. The attacker then crafts a malicious payload, not as a simple string, but as a complex DOM object. This object contains a node with a `nodeName` specifically designed to be misinterpreted by the vulnerable library. This payload is submitted to the application through a feature like a comment field or profile editor. When a victim visits the page, the application calls DOMPurify to sanitize the content. Due to the flaw, the malicious script embedded in the attacker's crafted object is not removed and executes in the victim's browser, giving the attacker control over their session.

How to fix it

The primary remediation is to upgrade the DOMPurify library to the latest patched version that addresses this vulnerability. If an immediate upgrade is not possible, a temporary mitigation is to disable the `IN_PLACE: true` configuration option. Instead, use DOMPurify's default behavior, which returns a sanitized string or DOM fragment that can then be safely inserted into the document. Review all instances where DOMPurify is used to ensure this high-risk option is disabled if the library cannot be updated.

How to confirm the fix worked

To validate the fix, first use a software composition analysis (SCA) tool or manually inspect dependency files (e.g., `package-lock.json`, `yarn.lock`) to confirm that the DOMPurify library has been upgraded to a patched version. Second, perform a code review to search for all usages of `DOMPurify.sanitize` and verify that any instances using the `{ IN_PLACE: true }` option are either removed or are used only with a patched version of the library. Finally, conduct dynamic application security testing (DAST) by attempting to submit proof-of-concept payloads designed to exploit this specific flaw to a test environment; a successful patch will neutralize the payload.

Typical attack path

1. Attacker identifies a web application using a vulnerable version of DOMPurify with the `IN_PLACE` option.
2. Attacker finds an input vector, such as a comment form or rich text editor, where user input is processed by the library.
3. Attacker crafts a malicious DOM object with a specially formed `nodeName` to bypass sanitization.
4. Attacker injects the malicious object into the application via the identified input vector.
5. A victim user browses the page containing the attacker's malicious content.
6. The victim's browser executes the unsanitized script, leading to session hijacking, data theft, or other malicious actions on behalf of the user.

How to detect it

Detecting exploitation of this client-side vulnerability is challenging. Review server-side application and web server logs for unusual or malformed submissions to endpoints known to use DOMPurify, looking for data that resembles JavaScript objects or contains unexpected HTML properties. If a Content Security Policy (CSP) with reporting is enabled, monitor violation reports for unexpected script execution events, which could indicate a successful XSS compromise. Network monitoring for unusual outbound requests from clients to unknown domains may also indicate data exfiltration by a malicious script.

What your security team should do

• Use a Software Composition Analysis (SCA) tool to immediately identify all applications using the DOMPurify library and flag vulnerable versions.
• Prioritize patching for all public-facing applications, especially those that process user-generated content.
• If patching cannot be performed immediately, issue guidance to development teams to disable the `IN_PLACE: true` configuration option as a critical mitigation step.
• Review Content Security Policy (CSP) configurations to ensure they are restrictive enough to prevent inline script execution and limit connections to trusted domains, which can mitigate the impact of a successful XSS attack.