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

[renovate-sh-app]

This PR contains the following updates:

Package	Change	Age	Confidence
dompurify	3.3.3 → 3.4.0

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)

---

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

• https://github.com/cure53/DOMPurify/security/advisories/GHSA-39q2-94rc-95cp
• https://github.com/cure53/DOMPurify

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.