Skip to content

chore(deps): update dependency dompurify to v3.4.0 [security]#727

Merged
renovate-sh-app[bot] merged 1 commit intomainfrom
renovate/security-npm-dompurify-vulnerability
Apr 22, 2026
Merged

chore(deps): update dependency dompurify to v3.4.0 [security]#727
renovate-sh-app[bot] merged 1 commit intomainfrom
renovate/security-npm-dompurify-vulnerability

Conversation

@renovate-sh-app
Copy link
Copy Markdown
Contributor

@renovate-sh-app renovate-sh-app Bot commented Apr 16, 2026

This PR contains the following updates:

Package Change Age Confidence
dompurify 3.3.33.4.0 age confidence

GitHub Vulnerability Alerts

GHSA-39q2-94rc-95cp

Summary

In src/purify.ts:1117-1123, ADD_TAGS as a function (via EXTRA_ELEMENT_HANDLING.tagCheck) bypasses FORBID_TAGS due to short-circuit evaluation.

The condition:

!(tagCheck(tagName)) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])

When tagCheck(tagName) returns true, the entire condition is false and the element is kept — FORBID_TAGS[tagName] is never evaluated.

Inconsistency

This contradicts the attribute-side pattern at line 1214 where FORBID_ATTR explicitly wins first:

if (FORBID_ATTR[lcName]) { continue; }

For tags, FORBID should also take precedence over ADD.

Impact

Applications using both ADD_TAGS as a function and FORBID_TAGS simultaneously get unexpected behavior — forbidden tags are allowed through. Config-dependent but a genuine logic inconsistency.

Suggested Fix

Check FORBID_TAGS before tagCheck:

if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }

Affected Version

v3.3.3 (commit 883ac15)

Severity
  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

DOMPurify's ADD_TAGS function form bypasses FORBID_TAGS due to short-circuit evaluation

GHSA-39q2-94rc-95cp

More information

Details

Summary

In src/purify.ts:1117-1123, ADD_TAGS as a function (via EXTRA_ELEMENT_HANDLING.tagCheck) bypasses FORBID_TAGS due to short-circuit evaluation.

The condition:

!(tagCheck(tagName)) && (!ALLOWED_TAGS[tagName] || FORBID_TAGS[tagName])

When tagCheck(tagName) returns true, the entire condition is false and the element is kept — FORBID_TAGS[tagName] is never evaluated.

Inconsistency

This contradicts the attribute-side pattern at line 1214 where FORBID_ATTR explicitly wins first:

if (FORBID_ATTR[lcName]) { continue; }

For tags, FORBID should also take precedence over ADD.

Impact

Applications using both ADD_TAGS as a function and FORBID_TAGS simultaneously get unexpected behavior — forbidden tags are allowed through. Config-dependent but a genuine logic inconsistency.

Suggested Fix

Check FORBID_TAGS before tagCheck:

if (FORBID_TAGS[tagName]) { /* remove */ }
else if (tagCheck(tagName) || ALLOWED_TAGS[tagName]) { /* keep */ }
Affected Version

v3.3.3 (commit 883ac15)

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N

References

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


Release Notes

cure53/DOMPurify (dompurify)

v3.4.0: DOMPurify 3.4.0

Compare Source

Most relevant changes:

  • Fixed a problem with FORBID_TAGS not winning over ADD_TAGS, thanks @​kodareef5
  • Fixed several minor problems and typos regarding MathML attributes, thanks @​DavidOliver
  • Fixed ADD_ATTR/ADD_TAGS function leaking into subsequent array-based calls, thanks @​1Jesper1
  • Fixed a missing SAFE_FOR_TEMPLATES scrub in RETURN_DOM path, thanks @​bencalif
  • Fixed a prototype pollution via CUSTOM_ELEMENT_HANDLING, thanks @​trace37labs
  • Fixed an issue with ADD_TAGS function form bypassing FORBID_TAGS, thanks @​eddieran
  • Fixed an issue with ADD_ATTR predicates skipping URI validation, thanks @​christos-eth
  • Fixed an issue with USE_PROFILES prototype pollution, thanks @​christos-eth
  • Fixed an issue leading to possible mXSS via Re-Contextualization, thanks @​researchatfluidattacks and others
  • Fixed an issue with closing tags leading to possible mXSS, thanks @​frevadiscor
  • Fixed a problem with the type dentition patcher after Node version bump
  • Fixed freezing BS runs by reducing the tested browsers array
  • Bumped several dependencies where possible
  • Added needed files for OpenSSF scorecard checks

Published Advisories are here:
https://github.com/cure53/DOMPurify/security/advisories?state=published


Configuration

📅 Schedule: (in timezone 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

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

| datasource | package   | from  | to    |
| ---------- | --------- | ----- | ----- |
| npm        | dompurify | 3.3.3 | 3.4.0 |


Signed-off-by: renovate-sh-app[bot] <219655108+renovate-sh-app[bot]@users.noreply.github.com>
@renovate-sh-app renovate-sh-app Bot force-pushed the renovate/security-npm-dompurify-vulnerability branch from a9eebd5 to 1407494 Compare April 22, 2026 16:02
@renovate-sh-app renovate-sh-app Bot merged commit fb79f50 into main Apr 22, 2026
23 checks passed
@renovate-sh-app renovate-sh-app Bot deleted the renovate/security-npm-dompurify-vulnerability branch April 22, 2026 16:10
@github-project-automation github-project-automation Bot moved this from Backlog to Complete in OSS Big Tent Apr 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Complete

Development

Successfully merging this pull request may close these issues.

0 participants