chore(deps): update dependency sanitize-html to v2.17.3 [security]#5269
Merged
renovate[bot] merged 1 commit intomasterfrom Apr 16, 2026
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
2.17.2→2.17.3GitHub Vulnerability Alerts
CVE-2026-40186
Summary
Commit 49d0bb7 introduced a regression in sanitize-html that bypasses
allowedTagsenforcement for text insidenonTextTagsArrayelements (textareaandoption). Entity-encoded HTML inside these elements passes through the sanitizer as decoded, unescaped HTML, allowing injection of arbitrary tags including XSS payloads. This affects any application using sanitize-html that includesoptionortextareain itsallowedTagsconfiguration.Details
The vulnerable code is at
packages/sanitize-html/index.js:569-573:The comment is factually incorrect. htmlparser2 10.x does decode HTML entities inside both
<textarea>and<option>elements before passing text to theontextcallback. This can be verified:Because the code assumes the text is "already properly encoded" and skips
escapeHtml(), the decoded entities (<,>) are written directly to the output as literal HTML characters. This completely bypasses theallowedTagsfilter — any tag can be injected inside an allowedoptionortextareaelement using entity encoding.The execution flow:
<option><img src=x onerror=alert(1)></option>ontextreceives<img src=x onerror=alert(1)>option, which is innonTextTagsArray→ trueresult += text— writes decoded text directly without escaping<option><img src=x onerror=alert(1)></option>—<img>tag injected despite not being inallowedTagsThe
scriptandstyletags are handled separately at lines 563-568 (before the vulnerable block), so the effective vulnerability applies totextareaandoption, plus any custom elements added tononTextTagsby the user.Prior to commit 49d0bb7, text in these elements fell through to the
escapeHtmlbranch (line 574-580), which correctly re-encoded the decoded entities.PoC
Prerequisites: Application using sanitize-html 2.17.2 with
optionortextareainallowedTags.Step 1: Basic tag injection via option
Step 2: Element breakout with XSS event handler
Step 3: Textarea breakout (also vulnerable)
Step 4: Full select/option context breakout
All outputs verified against sanitize-html 2.17.2 with htmlparser2 10.x.
Impact
allowedTagsbypass: Any HTML tag can be injected through an allowedoptionortextareaelement using entity encoding, defeating the core security guarantee of sanitize-html.optionortextareatags (common in form builders, CMS platforms, rich text editors) are vulnerable to stored cross-site scripting.onerror,onload, etc.) to steal session cookies or authentication tokens.allowedTagsdoes not includeoptionortextarea. However, these tags are commonly allowed in applications that handle form-related HTML content.Recommended Fix
Remove the vulnerable code block at lines 569-573 entirely. The
escapeHtmlbranch (line 574) correctly handles these elements — htmlparser2 10.x decodes entities, and re-encoding withescapeHtmlproduces correct HTML output (entities are round-tripped, not double-encoded).This fix restores the pre-49d0bb7 behavior where all non-script/style text content goes through
escapeHtml(), ensuring decoded entities are properly re-encoded before output.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:NRelease Notes
apostrophecms/apostrophe (sanitize-html)
v2.17.3Compare Source
Security
optiontags. There was no vulnerability when not explicitly allowingoptiontags.Configuration
📅 Schedule: (UTC)
🚦 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.
This PR was generated by Mend Renovate. View the repository job log.