GHSA-jxwj-j7wr-gfrw ApostropheCMS: Mutation-XSS / allowedTags bypass via literal `</textarea/>` solidus close

• npm sanitize-html: < 2.17.6 → fixed in 2.17.6

Summary A mutation-XSS / allowedTags bypass: when `textarea` (or `xmp`) is included in `allowedTags`, an input containing a literal `` (a solidus right after the RCDATA end-tag name) lets non-allowed markup such as `` pass through `sanitizeHtml()` live and unescaped, even though `img`/`onerror` are not in the allowlist. A spec-compliant browser executes the surviving handler — XSS. This is a literal-solidus variant that bypasses the two most recent fixes in this code area (CVE-2026-40186, CVE-2026-44990), both already applied in 2.17.5. The default configuration is not affected. Details `sanitize-html` emits the text content of HTML raw-text elements (`textarea`, `xmp`) without escaping. Two things combine: • Parser differential: on input, htmlparser2 does NOT recognize `` (solidus after the RCDATA end-tag name) as a close tag; it emits `` as a single raw-text node. • Unescaped passthrough: the `ontext` handler (`index.js` ~575-583) appends `textarea`/`xmp` content with `result += text` (no `escapeHtml`), assuming it is "already properly encoded" — true for entity-decoded content (what CVE-2026-40186 fixed) but false for this mis-tokenized literal close tag. A spec browser treats `` as a valid `textarea` close, so the following `` is parsed as a live element. The recent fixes addressed entity-encoding (CVE-2026-40186) and the `xmp` default (CVE-2026-44990); neither covers the literal-solidus mis-tokenization, so the raw passthrough still leaks. PoC ```js // npm i [email protected] parse5 && node poc.js const sanitizeHtml = require('sanitize-html'); const input = ''; const opts = { allowedTags: sanitizeHtml.defaults.allowedTags.concat(['textarea']) }; // img NOT allowed console.log(sanitizeHtml(input, opts)); // => // the survives live and unescaped console.log(sanitizeHtml(input)); // default config (no textarea allowed) => "" (safe) ``` Re-parsing the sanitized OUTPUT with parse5 (the WHATWG HTML parser browsers/jsdom use) yields a live `` at `body` level (it escaped the textarea RCDATA, not inert text) → the `onerror` fires in a browser. Confirmed on 2.17.5 (Node v24). A canonical `poc.js` is attached. Impact Cross-site scripting (CWE-79). Requires `textarea` (or `xmp`) in `allowedTags` — a benign-looking, common addition in form builders, CMS, and rich-text editors. Adding a harmless tag that then enables XSS via *non-allowed* `img`/`onerror` breaks the sanitizer's core contract; the maintainers have fixed this class before (e.g. GHSA-9mrh). An attacker who can submit content rendered through such a configuration achieves stored/reflected XSS (cookie theft, session hijack). Severity Medium (default config is safe; user interaction to view the page). Suggested fix: route `textarea`/`xmp` content through `escapeHtml` instead of the raw passthrough, and/or fix the htmlparser2 `` RCDATA end-tag tokenization to match the WHATWG spec.