Skip to content

fix(deps): update dependency sanitize-html to v2.18.1 [security] - #673

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-sanitize-html-vulnerability
Open

renovate[bot] wants to merge 1 commit into
mainfrom
renovate/npm-sanitize-html-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Oct 25, 2026 •

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
sanitize-html (source) 2.18.0 → 2.18.1 age confidence

ApostropheCMS sanitize-html: unbounded recursion when re-sanitizing the fallback of a discarded iframe (stack overflow, nestingLimit not enforced)

CVE-2026-113650 / GHSA-c9rx-x947-fp3h

More information

Details

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
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
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:

} 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.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

apostrophecms/apostrophe (sanitize-html)

v2.18.1

Compare Source

Changes
  • Remove the deepmerge dependency, which was used only to combine tag-specific and * (all tags) entries in allowedClasses and allowedStyles. That is now done by a few lines of code within sanitize-html.

    This is not a fix for a vulnerability in sanitize-html. Security scanners such as Snyk now report CVE-2026-93753 in deepmerge, which can affect applications that merge untrusted objects, such as parsed JSON request bodies. sanitize-html only ever merged the developer's own configuration, never anything taken from the HTML being sanitized, so it was not exploitable through sanitize-html. Since we needed only a small part of what deepmerge does, we removed the dependency so that these reports no longer appear for sanitize-html users.

Security
  • Since 2.18.0, the fallback markup of a discarded <iframe> was re-sanitized by a recursive call with no limit, one level per nested unclosed <iframe>. A few kilobytes of crafted input could throw RangeError: Maximum call stack size exceeded with the default options, and the nestingLimit option was not enforced across the fallback because each nested call started counting from zero. The fallback of a discarded <iframe> is still sanitized and kept, but only up to eight nested <iframe> elements (deeper fallback is escaped as text, as before 2.18.0), and the current nesting depth now carries into the nested call so nestingLimit applies to the whole output. Only 2.18.0 was affected, and the exception is thrown synchronously, so applications that catch errors from sanitizeHtml only lost the affected request (CWE-674, GHSA-c9rx-x947-fp3h).

    Thanks to hkmj19, JohnBeckley, and amikhailovstiltsoft for reporting the vulnerability.


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot added the security Pull requests that address a security vulnerability label Oct 25, 2026
@renovate
renovate Bot force-pushed the renovate/npm-sanitize-html-vulnerability branch from 46a216e to 32d2f33 Compare October 26, 2026 20:34

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

security Pull requests that address a security vulnerability

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants