GHSA-87xg-pxx2-7hvx DOMPurify XSS via selectedcontent re-clone

• npm dompurify: >= 3.4.4, < 3.4.5 → fixed in 3.4.5

Summary DOMPurify 3.4.4 allows `selectedcontent` by default, allowing a chain in which browsers "re-clone" an XSS payload after sanitization, effectively bypassing DOMPurify. Details The chain is as follows: 1. The browser parses the input and creates a `` clone from the selected `` 2. DOMPurify walks and sanitizes that generated clone. 3. DOMPurify reaches the original `` and removes `selected=javascript:1` 4. The browser refreshes the `` clone from the original `option`'s content. 5. The refreshed clone is in a subtree DOMPurify already walked, which DOMPurify doesn't go back to sanitize 6. The returned string contains unsanitized markup inside ``. PoC ```js const dirty = '' + '' + 'x' + ''; const clean = DOMPurify.sanitize(dirty); console.log(clean); document.body.innerHTML = clean; ``` Observed "sanitized" output in Chromium 148/WebKit 625: ```html xx ``` After reinsertion, the browser updates the live DOM and strips the handler from the displayed clone, but the `onerror` has already fired: ```html xx ``` Reproduced in Chromium and WebKit, but not Safari (not yet latest WebKit) or Firefox. Will likely change with browser support for `selectedcontent`. Impact This is a default-configuration DOMPurify sanitizer bypass resulting in XSS. Applications are impacted if they sanitize attacker-controlled HTML with DOMPurify 3.4.4 using the string-input path and then insert the returned string into the page, for example with innerHTML.