Skip to content

Bump sanitize-html from 2.13.0 to 2.18.1 - #721

Open
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/sanitize-html-2.18.1
Open

dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/npm_and_yarn/sanitize-html-2.18.1

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Oct 20, 2026

Copy link
Copy Markdown
Contributor

Bumps sanitize-html from 2.13.0 to 2.18.1.

Changelog

Sourced from sanitize-html's changelog.

2.18.1 (2026-10-14)

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.

2.18.0 (2026-09-30)

Adds

  • Added a logger option: pass any console-shaped object, with debug, info, warn and error methods, and sanitize-html's own diagnostics are delivered to it rather than to the console, so an application with a logging pipeline of its own can route them. Missing methods, and no option at all, fall back to the console. Those messages also lost their decorative line breaks and warning icon, so each is now a single line of text; their wording is otherwise unchanged.

Fixes

  • allowedSchemesByTag is now applied to srcset and imagesrcset URLs. Previously the per-tag lookup used the attribute name instead of the tag name, so these attributes always fell back to the global allowedSchemes and ignored a tag-specific scheme allowlist. Thanks to spokodev for the fix.
  • Starting in version 2.17.6, sanitize-html began escaping any markup preserved inside a disallowed iframe tag, which was a change in behavior due to an upstream change in htmlparser2. This fix ensures such "fallback markup" is preserved without escaping, but also fully sanitized according to the same rules as the original input. Thanks to sumitjhacodes for the fix.

Security

  • When meta was allowed together with its http-equiv and content attributes, the destination URL of a <meta http-equiv="refresh" content="0;url=..."> was never checked against allowedSchemes, because it is embedded in content rather than being an attribute of its own. So javascript:, data: and other disallowed destinations passed through. The refresh URL is now extracted the way browsers do it, allowing for the different spellings, separators, quoting and letter case of url=, and checked against allowedSchemes (or allowedSchemesByTag.meta). If it is rejected, or the content cannot be parsed as a refresh, the content attribute is removed. content on other meta elements is unchanged. The default configuration does not allow meta and was not affected (CWE-79, CWE-601, GHSA-cv27-6wvh-8x7j).

    Thanks to adrbogacz for reporting the vulnerability.

  • When noscript is listed in nonTextTags, the discarded region could end too early. Browsers with scripting enabled treat <noscript> content as raw text up to the first </noscript>, but the underlying parser treats it as markup, so an end tag for an enclosing element inside <noscript> closed it implicitly and the rest of its content was emitted as ordinary sanitized markup. The discard region now continues until the point where a browser would end the <noscript> element, while implied closes of other nonTextTags such as <option> behave as before (CWE-79, CWE-436, GHSA-x3q4-9hxx-gx8m).

    Thanks to joaquiniglesiaslug for reporting the vulnerability.

  • The check that drops SVG animation elements (animate, animateColor, animateMotion, animateTransform, set) when they retarget a URL attribute such as href compared the full tag name, so a namespace-prefixed spelling like svg:animate was not recognized when such tags were allowed (for example with allowedTags: false). In XML serializations such as XHTML or standalone SVG, the prefixed element is a real animation element and could retarget a link to a javascript: URL after sanitization. The element and attributeName are now matched by their local names, ignoring any prefix (CWE-79, CWE-184, GHSA-374f-7chj-9948).

    Thanks to Kai Aizen (SnailSploit) for reporting the vulnerability.

2.17.7 (2026-08-13)

Security

  • Fixed an XSS / URL scheme policy bypass affecting configurations that allow the SVG animation elements (animate, animateColor, animateMotion, animateTransform or set) together with attributeName and one of the animation value attributes. The default configuration was not affected, as these elements are not in the default allowedTags. apostrophecms was not affected. Thanks to koyokr for responsibly disclosing the vulnerability (GHSA-g8qq-57p8-ggw5).

2.17.6 (2026-07-10)

... (truncated)

Commits

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    You can disable automated security fix PRs for this repo from the Security Alerts page.

Bumps [sanitize-html](https://github.com/apostrophecms/apostrophe/tree/HEAD/packages/sanitize-html) from 2.13.0 to 2.18.1.
- [Changelog](https://github.com/apostrophecms/apostrophe/blob/main/packages/sanitize-html/CHANGELOG.md)
- [Commits](https://github.com/apostrophecms/apostrophe/commits/sanitize-html@2.18.1/packages/sanitize-html)

---
updated-dependencies:
- dependency-name: sanitize-html
  dependency-version: 2.18.1
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot
dependabot Bot requested a review from a team as a code owner October 20, 2026 20:36
@dependabot dependabot Bot added the dependencies Pull requests that update a dependency file label Oct 20, 2026

This branch had an error being deployed

1 failed deployment
production — 30c426f0 Deployed Oct 20, 2026 by dependabot[bot] via docker-latest #1064
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants