GHSA-c9rx-x947-fp3h

### Summary Since 2.18.0, when an `<iframe>` is not allowed and `disallowedTagsMode` is `'discard'` (the defaults), its raw-text content is re-sanitized by a recursive call to `sanitizeHtml(text, options)` (the change from #5564, fixing #5550). The recursion has no bound and starts each nested call with a fresh state. Two consequences, both absent from 2.17.7 and 2.17.4: 1. A few kilobytes of unclosed `<iframe>` tags throw `RangeError: Maximum call stack size exceeded` with the default options. Any application that sanitizes untrusted HTML with 2.18.0 can be made to throw on a small crafted input. 2. `nestingLimit` is not enforced across a discarded iframe: each nested iframe restarts the depth count at zero, so the output can be nested arbitrarily deep regardless of the configured limit. ### Affected versions - 2.18.0 (the current `latest`), and the `main` branch at the time of writing (the recursive call is still in `packages/sanitize-html/index.js`, in the `ontext` handler, branch `tag === 'iframe' && !tagAllowed(tag) && options.disallowedTagsMode === 'discard'`). - Not affected: 2.17.7 and 2.17.4 (tested with the same inputs below). Tested with Node.js v26.7.0. ### Reproduction 1: stack overflow with the default options ```js const sanitizeHtml = require('sanitize-html'); // with 2.18.0: sanitizeHtml('<iframe>'.repeat(1000)); // 8,000 chars: returns '' sanitizeHtml('<iframe>'.repeat(2000)); // 16,000 chars: throws RangeError: Maximum call stack size exceeded sanitizeHtml('<iframe>'.repeat(20000)); // 160,000 chars: throws RangeError: Maximum call stack size exceeded ``` Results: | input | 2.17.4 | 2.17.7 | 2.18.0 | |---|---|---|---| | `'<iframe>'.repeat(1000)` | ok | ok | ok | | `'<iframe>'.repeat(2000)` | ok | ok | RangeError | | `'<iframe>'.repeat(20000)` | ok | ok | RangeError | The threshold depends on the remaining stack, so it is lower when `sanitizeHtml` is called from an already deep call stack (for example inside a server-side rendering pass). ### Reproduction 2: `nestingLimit` is bypassed ```js const sanitizeHtml = require('sanitize-html'); const input = ('<iframe>' + '<b>'.repeat(3)).repeat(50) + 'x'; const out = sanitizeHtml(input, { allowedTags: ['b'], nestingLimit: 3 }); // maximum nesting depth of <b> in `out`: // 2.17.4: 2 2.17.7: 0 (fallback escaped as text) 2.18.0: 150 ``` Without an iframe, the same options cap the output at three nested `<b>` in all three versions. With `k` repetitions of `'<iframe>' + '<b>'.repeat(3)`, 2.18.0 returns `3 * k` nested `<b>` (measured for k = 1, 5, 50: depth 3, 15, 150). ### Cause In 2.18.0 the `ontext` handler does: ```js } else if ( tag === 'iframe' && !tagAllowed(tag) && options.disallowedTagsMode === 'discard' ) { result += sanitizeHtml(text, options); } ``` Because htmlparser2 treats `<iframe>` as a raw-text element, the text of an unclosed iframe is the whole remainder of the input; re-parsing it can meet another unclosed `<iframe>`, and so on, one stack frame (and one full re-parse) per iframe. The nested call also starts with its own `depth`, so tags inside the fallback are not counted against `nestingLimit` together with the enclosing tags. ### Possible directions Not a patch, only what would close both effects: bound the recursion (or process the fallback without recursing), and carry the current depth into the nested sanitization so that `nestingLimit` applies to the whole output.