https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 01:53:28 +0000 https://vulnerability.circl.lu/vuln/ghsa-h8r8-wccr-v5f2 <p><strong>Affected:</strong> npm: dompurify</p> <p>## Description</p> <p>A mutation-XSS (mXSS) condition was confirmed when sanitized HTML is reinserted into a new parsing context using `innerHTML` and special wrappers. The vulnerable wrappers confirmed in browser behavior are `script`, `xmp`, `iframe`, `noembed`, `noframes`, and `noscript`. The payload remains seemingly benign after `DOMPurify.sanitize()`, but mutates during the second parse into executable markup with an event handler, enabling JavaScript execution in the client (`alert(1)` in the PoC).</p> <p>## Vulnerability</p> <p>The root cause is context switching after sanitization: sanitized output is treated as trusted and concatenated into a wrapper string (for example, `&lt;xmp&gt; ... &lt;/xmp&gt;` or other special wrappers) before being reparsed by the browser. In this flow, attacker-controlled text inside an attribute (for example `&lt;/xmp&gt;` or equivalent closing sequences for each wrapper) closes the special parsing context early and reintroduces attacker markup (`&lt;img ... onerror=...&gt;`) outside the original attribute context. DOMPurify sanitizes the original parse tree, but the application performs a second parse in a different context, reactivating dangerous tokens (classic mXSS pattern).</p> <p>## PoC</p> <p>1. Start the PoC app: ```bash npm install npm start ```</p> <p>2. Open `http://localhost:3001`. 3. Set `Wrapper en sink` to `xmp`. 4. Use payload: ```html &lt;img src=x alt=&#34;&lt;/xmp&gt;&lt;img src=x onerror=alert(&#39;expoc&#39;)&gt;&#34;&gt; ```</p> <p>5. Click `Sanitize + Render`. 6. Observe: - `Sanitized response` still contains t…</p> <p><strong>Affected:</strong> npm: dompurify</p> <p>## Description</p> <p>A mutation-XSS (mXSS) condition was confirmed when sanitized HTML is reinserted into a new parsing context using `innerHTML` and special wrappers. The vulnerable wrappers confirmed in browser behavior are `script`, `xmp`, `iframe`, `noembed`, `noframes`, and `noscript`. The payload remains seemingly benign after `DOMPurify.sanitize()`, but mutates during the second parse into executable markup with an event handler, enabling JavaScript execution in the client (`alert(1)` in the PoC).</p> <p>## Vulnerability</p> <p>The root cause is context switching after sanitization: sanitized output is treated as trusted and concatenated into a wrapper string (for example, `&lt;xmp&gt; ... &lt;/xmp&gt;` or other special wrappers) before being reparsed by the browser. In this flow, attacker-controlled text inside an attribute (for example `&lt;/xmp&gt;` or equivalent closing sequences for each wrapper) closes the special parsing context early and reintroduces attacker markup (`&lt;img ... onerror=...&gt;`) outside the original attribute context. DOMPurify sanitizes the original parse tree, but the application performs a second parse in a different context, reactivating dangerous tokens (classic mXSS pattern).</p> <p>## PoC</p> <p>1. Start the PoC app: ```bash npm install npm start ```</p> <p>2. Open `http://localhost:3001`. 3. Set `Wrapper en sink` to `xmp`. 4. Use payload: ```html &lt;img src=x alt=&#34;&lt;/xmp&gt;&lt;img src=x onerror=alert(&#39;expoc&#39;)&gt;&#34;&gt; ```</p> <p>5. Click `Sanitize + Render`. 6. Observe: - `Sanitized response` still contains t…</p> https://vulnerability.circl.lu/vuln/ghsa-h8r8-wccr-v5f2